Porządny Agile

“Musimy się lepiej komunikować” – czy zdarza się, że słyszysz to w swoich zespołach? Niby proste hasło, ale często nikt nie wie, co to właściwie znaczy i jak to zrobić.Rozłożyliśmy efektywność komunikacji na czynniki pierwsze. Zdefiniowaliśmy ją i pokazaliśmy praktyki  komunikacji nie tylko w zespołach projektowych, ale też managerskich. Skorzystaj z naszych sprawdzonych rekomendacji, które możesz wdrożyć od razu by komunikacja stała się efektywna. Porządny Agile · Efektywna komunikacja Jak rozumiemy efektywność komunikacji? Za każdym razem, gdy mówimy o efektywności, mamy na myśli relację wartości uzyskanej z danej czynności do kosztu jej uzyskania. Oczekiwalibyśmy więc, aby komunikacja dawała jak najwięcej wartości. Była z tej perspektywy efektywna przy jak najniższym koszcie doprowadzenia do sytuacji, w której efektywność oceniamy jako wysoką. Przykładowo możesz mieć bardzo długie spotkanie, na które zaproszono wiele osób, a efekt tego spotkania wcale nie będzie spektakularny. W takiej sytuacji mówimy o niskiej efektywności. Z drugiej strony możesz mieć krótkie spotkanie, w którym uczestniczy jedynie kilka osób. Natomiast wnioski, z którymi wraz z grupą wychodzisz z takiego spotkania, mogą być bardzo wartościowe i mogą rozwijać biznes do przodu. W takim przypadku uznamy komunikację za efektywną. Spis treści Jak rozumiemy efektywność komunikacji?Praktyki i rozwiązania: jak podnieść efektywność komunikacji w zespole?Jak usprawnić efektywność komunikacji zespołu?Transkrypcja podcastu „Efektywna komunikacja„ Wyzwanie w tym podejściu, mimo że sama filozofia jest prosta, polega na precyzyjnym określeniu wartości komunikacji. Koszt jest zazwyczaj widoczny gołym okiem. Są to elementy łatwe do policzenia, natomiast wartość dodana jest znacznie trudniejsza do uchwycenia. Proponujemy uproszczone podejście, bez dosłownego trzymania się wzoru kosztu i korzyści. Można przyjąć, że efektywność pracy zespołu lub efektywność jego komunikacji ma pewien poziom, który wymaga analizy, jak konkretne zmiany w przepływie informacji wpływają na wyniki. Nie ma potrzeby precyzyjnego określania wartości obecnej ani wyliczania wartości całkowitej, wystarczy oszacować różnicę. Analizujemy dodatkową korzyść wynikającą z lepszej komunikacji oraz dodatkowe koszty lub oszczędności uzyskane dzięki poprawie praktyk komunikacyjnych. Nakłady najczęściej wiążą się z czasem zespołu, kilku lub kilkunastu osób uczestniczących w działaniach komunikacyjnych. Może to być spotkanie, praca warsztatowa lub większe spotkanie zespołowe, ale również czas poświęcony na napisanie wiadomości e-mail, który także jest elementem komunikacji. Czas potrzebny na jej napisanie, przeczytanie i zrozumienie również stanowi koszt. Po oszacowaniu kosztów i wartości dodanej nie stanowi wartości bezwzględnej, lecz pozwalają ocenić zmianę efektywności, co jest wystarczające do optymalizacji pracy zespołu oraz dalszej analizy kolejnych zagadnień. Praktyki i rozwiązania: jak podnieść efektywność komunikacji w zespole? 1. Komunikuj się bez pośredników Chodzi o unikanie pośrednictwa w komunikacji i bezpośrednie porozumiewanie się wszędzie tam, gdzie jest to możliwe. Jest to praktyka dość oczywista z perspektywy efektywności, ponieważ każda kolejna osoba w łańcuchu komunikacji generuje dodatkowy koszt. Z drugiej strony każdy pośrednik może obniżać wartość uzyskaną z komunikacji, ponieważ część informacji może zostać zniekształcona lub niedopowiedziana, a sama komunikacja przestaje być tak skuteczna, jak zakładano. Mamy wyraźną preferencję dla komunikacji bezpośredniej. Poniżej dwie konkretne praktyki z życia biznesowego:  skip level – chodzi o obejście klasycznej hierarchii, w której przełożony rozmawia wyłącznie z podwładnymi, dyrektor z kierownikami, a prezes jedynie z dyrektorami. W praktyce skip level polega na tym, że członek zarządu rozmawia bezpośrednio z przedstawicielami zespołów projektowych, ewentualnie w towarzystwie menedżerów pośredniego szczebla, ale nie ogranicza się wyłącznie do komunikacji za ich pośrednictwem, co jest istotą tej praktyki. Czasami taka okazja pojawia się naturalnie, a czasami wymaga stworzenia pretekstu, innym razem wynika z firmowych rutyn, ale kluczowe jest znalezienie sposobu, aby osoby wyżej w strukturze mogły zrozumieć perspektywę pracowników pierwszego poziomu poprzez bezpośrednią rozmowę lub obserwację. Takimi okazjami mogą być podsumowania projektów, ich rozpoczęcia, ale również rozmowy dotyczące usprawnień czy zmiany strategii. Powodów i kontekstów w różnych organizacjach może być wiele. Kluczowe jest przełamanie zasady, zgodnie z którą wiedza o tym, co dzieje się w firmie, pochodzi wyłącznie od bezpośredniego szczebla zarządzania. udział w warsztatach z przedstawicielami klienta – niezależnie od tego, czy pełnisz rolę bezpośrednio pracującą z rynkiem, na przykład w sprzedaży, obsłudze klienta, rozwoju produktu lub rozwoju biznesu. Nawet jeśli nie pracujesz w takich rolach, warto od czasu do czasu mieć okazję do bezpośredniego kontaktu z klientem, nawet w zaaranżowanych warunkach. Pozwala to lepiej zrozumieć potrzeby klienta, język, którym się posługuje, oraz towarzyszące mu emocje, a także konkretne, zgłaszane przez niego potrzeby, co pozwala ograniczyć ryzyko zniekształcenia komunikatu przez pośredników stojących między Tobą a rynkiem oraz utraty okazji do wartościowych spostrzeżeń.  Powtarzamy również istotne zastrzeżenie dotyczące tej praktyki: wszystko należy rozpatrywać z perspektywy efektywności. Praktyki takie jak skip level są kosztowne, ponieważ osoby wysoko w hierarchii organizacji poświęcają czas na dodatkowe spotkania, których w innych warunkach można byłoby uniknąć. Podobnie warsztaty z przedstawicielami klienta wymagają czasu i odciągają od innych obowiązków. Z naszego doświadczenia wynika jednak, że w obu tych praktykach pojawia się istotna wartość dodatkowa wynikająca z lepszych rozwiązań, szerszej perspektywy i trafniejszych decyzji, co ostatecznie przekłada się na lepszy rezultat. 2. Twórz warunki do współdziałania To dość ogólna rekomendacja, ale chodzi w niej o takie układanie współpracy, aby komunikacja pojawiała się przy jej okazji, a nie służyła jedynie łączeniu pracy wykonywanej w izolacji. W tej poradzie przyjmujemy tezę, że skuteczna komunikacja pojawia się naturalnie przy okazji współpracy, gdy co najmniej dwie osoby w zespole lub grupie zadaniowej wspólnie tworzą coś razem, a komunikacja nie jest odrębną aktywnością oderwaną od pozostałych działań w organizacji. Przykładowo, wyobraź sobie sytuację, w której konieczna jest reorganizacja i w Twojej organizacji trzeba zmienić strukturę. Reorganizacja, jej powody oraz konkretne rozwiązania będą najlepiej zrozumiane, jeśli zespół liderów i osób zaangażowanych w zmianę będzie ją jednocześnie współtworzył. Prace możesz zacząć od brudnopisu, niepełnych pomysłów, a nawet sprzecznych koncepcji, jednak w trakcie tego procesu pojawi się potrzeba intensywnej komunikacji, co sprawi, że będzie sumarycznie bardzo efektywna. Owszem, wymaga to poświęcenia czasu na dość żmudny proces dochodzenia do ustaleń, ale jednocześnie ustalenia te będą bardzo dobrze rozumiane, ponieważ wszyscy zaangażowani uczestniczyli w tym procesie. Jest to przykład dość kontrowersyjny i jeden z bardziej wymagających, zwłaszcza jeśli reorganizacja wiąże się ze zmianami personalnymi, ale można go również odnieść do pracy projektowej, pracy nad pomysłem lub nowym produktem, albo do zmian o mniejszej skali, które nadal wymagają dobrej komunikacji. Przy tej okazji warto wspomnieć, że wiąże się to z zależnością jakości komunikacji od narzędzia, które jest stosowane. Upraszczając, najsłabszym narzędziem jest przesyłanie dokumentów lub opracowań w formie pisemnej. Rozmowa zajmuje w tym zestawieniu pozycję pośrednią. Najlepsze efekty przynosi wspólna praca nad jednym dokumentem, szkicem, draftem lub konkretną koncepcją, jednak ma to sens tylko przy istotnym zastrzeżeniu, że chodzi o wypracowywanie złożonych koncepcji. Oczywiście nadal istnieją sytuacje, w których najbardziej efektywne będzie napisanie dobrze skonstruowanej wiadomości e–mail, natomiast wszędzie tam, gdzie coś jest tworzone lub wspólnie wypracowywane, a poziom złożoności rośnie, tym większą korzyść przynosi faktyczna, bliska współpraca. Rolą lidera w tym układzie jest tworzenie warunków do współdziałania, zachęcanie do niego, pokazywanie dobrych praktyk oraz korzystanie z takich narzędzi, tak aby osoby w zespole miały okazję zobaczyć, jak takie współdziałanie wygląda w praktyce. 3. Zbliż się w komunikacji Wychodzimy z założenia, że dobra komunikacja wymaga fizycznej lub symbolicznej bliskości. Co to oznacza w praktyce? W pracy stacjonarnej może to oznaczać pracę w jednej przestrzeni. W takiej sytuacji często wystarczy obrócić krzesło, aby coś skomentować lub o coś dopytać. Pojawia się tu również zjawisko komunikacji przez osmozę, czyli możliwość przypadkowego usłyszenia informacji w open space lub we wspólnej przestrzeni, która może okazać się istotna, nawet jeśli została odebrana mimowolnie, albo informacji, którą warto uzupełnić lub skorygować. Przykładem takiego zbliżenia jest również czat grupowy, w którym wszyscy mają dostęp do informacji przepływających w ramach pracy zespołu. Jeśli spotkanie odbywa się online, warto zadbać o to, aby możliwie najbardziej przypominało spotkanie fizyczne. Z naszego doświadczenia wynika, że istotny jest nie tylko kontakt słowny, ale również możliwość zobaczenia rozmówcy, dlatego warto korzystać z kamery, aby dostrzegać sygnały niewerbalne, oraz zadbać o dobrą jakość połączenia, zarówno obrazu, jak i dźwięku. Obecnie nie ma istotnych przeciwwskazań technologicznych, aby skutecznie komunikować się na odległość. Można z lekkim przekąsem zauważyć, że mamy 2026 rok, a jakość komunikacji online nadal bywa wyzwaniem, nawet w zespołach, które pracują w trybie hybrydowym od kilku lat. Zamiast kolejnego przykładu z obszaru pracy zespołowej przyto

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 Spis treści Definicja przewidywalnościJak mierzyć przewidywalność?Wskazówki na temat stosowania miary przewidywalnościJak poprawiać przewidywalność zespołu?FAQ: Przewidywalność zespołuTranskrypcja podcastu „Przewidywalność zespołu” Definicja przewidywalności Przewidywalność rozumiemy jako to, w jakim stopniu zespół dowozi lub dostarcza to, co zaplanował. W jakim stopniu realizuje plan, który przyjął? Czy jeśli zespół mówi, że coś zostanie zrealizowane, to faktycznie tak się stanie? Z jakim prawdopodobieństwem zespół realizuje swoje zamiary. Z jednej strony jest to miara, do której można wrócić w dalszej części, ponieważ da się ją wyrazić w sposób precyzyjny…a z drugiej, mówiąc o przewidywalności zespołu, mamy na myśli cechę, którą warto uznawać za pożądaną. To zespół, na którego prognozach organizacja może polegać. Dla równowagi warto doprecyzować, czym przewidywalność – w naszym rozumieniu – nie jest, mimo że bywa tak postrzegana. Przewidywalność bywa utożsamiana z ogólnym prawdopodobieństwem dostarczania, niezależnie od jego poziomu lub dużej zmienności. W sensie czysto matematycznym nadal mieści się to w definicji, podobnie jak smród jest zapachem, a brunatny jest kolorem… jednak przewidywalność postrzegamy jako zjawisko pozytywne, pożądane. Nie uznajemy za sukces sytuacji, w której zespół dostarcza jedno zadanie na cztery lub realizuje jedynie 20% planu, mimo że taki poziom również może być „przewidywalny”. Choć w ujęciu matematycznym nadal można to nazwać przewidywalnością, odcinamy się od takiego podejścia. Przewidywalność rozumiemy jako korzystną cechę zespołu. To cecha, która powinna zmierzać ku konkretnym, ambitnym wartościom. Przewidywalny zespół to ten, który dostarcza to, co zaplanuje, nie tylko tyle, ile zazwyczaj udaje mu się osiągnąć. Nawet jeśli ta „zazwyczaj osiągana” wartość jest bardzo niska. Zespół, który regularnie dostarcza mało, nie jest dla nas przewidywalny, nawet jeśli działa w sposób powtarzalny. Jak mierzyć przewidywalność? Ogólny sposób obliczania jest dość prosty. W uproszczeniu: to stosunek wartości faktycznie zrealizowanej w danej iteracji (np. Sprincie) do wartości uprzednio zaplanowanej. W większości przypadków wyraża się to w procentach. W szczegółach może się to okazać znacznie bardziej złożone. Poszczególne zespoły uwzględniają w tym wzorze różne elementy składowe. Najprostsze podejście polega na uwzględnieniu wszystkich elementów realizowanych przez zespół, niezależnie od typu pracy czy rodzaju planowanych zadań w iteracji. Część zespołów decyduje się jednak na mierzenie przewidywalności wyłącznie na podstawie historyjek użytkownika (tzw. storki), niezależnie od przyjętej lokalnej terminologii. W innych przypadkach brane są pod uwagę tylko funkcjonalności lub wyłącznie prace rozwojowe. Zdarza się też, że zespoły uwzględniają zadania techniczne lub podzadania niezbędne do realizacji zaplanowanej pracy. Kontrowersyjne bywa włączanie do kalkulacji przewidywalności błędów zaplanowanych do rozwiązania, mimo że są one znane już na początku Sprintu. Podobne wątpliwości może budzić uwzględnianie zadań utrzymaniowych, powtarzalnych czynności, które muszą zostać wykonane niezależnie od okoliczności i regularnie pojawiają się w iteracjach. Warto jednak zaznaczyć, że sposób uwzględniania typów pracy w mierzeniu przewidywalności to temat wart refleksji. To obszar, który wymaga świadomego zaplanowania i doprecyzowania, co dokładnie zostanie ujęte w wzorze stosowanym przez konkretny zespół. Jeśli zespół zaplanował dostarczenie 10 elementów, a zrealizował tylko 2 – przewidywalność wynosi 20%. Przy realizacji 5 z 10 zaplanowanych elementów przewidywalność wynosi 50%. Jeśli zaplanowano 10, a dostarczono 12 – przewidywalność osiąga poziom 120%. Przewidywalność to miara, w której wartość oczekiwana mieści się w pewnym akceptowalnym zakresie. Zakresem uznawanym za wart rozmowy jest przedział 80 a 120%. Istotniejsze jest utrzymywanie się w tym zakresie niż osiąganie konkretnego, precyzyjnego wyniku. Powtarzalne osiąganie dokładnie 100% może świadczyć o tym, że miara została potraktowana jako cel sam w sobie. Zakres zdrowej przewidywalności można porównać do przedziałów referencyjnych w wynikach badań krwi. Otrzymujemy listę wyników wraz z informacją, czy konkretna wartość mieści się w normie lub spodziewanym zakresie. Bardzo podobnie działa to w przypadku przewidywalności. W kontekście przewidywalności warto również wspomnieć, jak można ją mierzyć w praktyce, za pomocą narzędzi. Innymi słowy, w jaki sposób technicznie przeprowadzić taki pomiar. JIRA (Velocity Chart) Najczęściej spotykanym narzędziem w organizacjach, jest JIRA.Wystarczy przejść do sekcji raportów i wybrać wykres Velocity Chart (w wersji anglojęzycznej). Na wykresie znajdziesz zarówno informację o faktycznie zrealizowanej pracy (prędkość zespołu), jak i o zakresie pracy zaplanowanej na dany Sprint. Dane te powinny pojawić się automatycznie, pod warunkiem zachowania podstawowej higieny pracy w JIRA. Oznacza to m.in. prawidłowe uruchamianie Sprintów. Sprint powinien wystartować w faktycznym momencie jego rozpoczęcia, a zakończony dokładnie w momencie jego ukończenia. W jego zakresie powinna znaleźć się realnie wykonywana praca. Równie istotna jest poprawna konfiguracja boardu, jak i samego projektu, który zespół realizuje. Przy takim podejściu wykres otrzymujemy „z pudełka”, bez dodatkowej konfiguracji. Nie jest potrzebna żadna dodatkowa konfiguracja, aby sprawdzić, jak historycznie kształtowała się przewidywalność zespołu. Excel W porównaniu z JIRA, Excel oferuje znacznie większą elastyczność, choć dane nie zbierają się automatycznie, jak ma to miejsce w JIRA. Przy zachowaniu podstawowej dyscypliny pracy, JIRA zlicza dane samodzielnie. W Excelu natomiast konieczne jest ręczne wprowadzanie danych, najczęściej przez osobę odpowiedzialną za proces, członka zespołu lub jego lidera. Należy pamiętać o przeniesieniu danych historycznych i użyciu odpowiednich formuł, aby uzyskać oczekiwany wynik. Choć jest to praca wymagająca większego zaangażowania, to w sytuacjach bardziej złożonych lub wymagających większej precyzji w doborze danych do analizy, Excel może okazać się bardziej wiarygodnym i lepiej kontrolowanym rozwiązaniem niż narzędzia generujące wynik na podstawie filtrów lub niewłaściwie prowadzone. Mural, Miro, kartka papieru Innymi narzędziami mogą być wszelkiego rodzaju rozwiązania wspierające wizualizację pracy oraz powiązanych z nią koncepcji. W warunkach pracy zdalnej mogą to być narzędzia takie jak Mural czy Miro. W pracy stacjonarnej równie dobrze sprawdzi się tablica, flipchart czy nawet kartka papieru. Kluczowe jest, aby dane znalazły się w miejscach, wokół których zespół będzie się koncentrować. Na podstawie obserwacji, zespoły pracujące zdalnie często prowadzą refleksję np. na Muralu. W takim przypadku śledzenie informacji procesowych, w szczególności dotyczących przewidywalności, może być naturalnym elementem, który i tak zostanie uwzględniony podczas cotygodniowej lub dwutygodniowej refleksji. Posiadanie kompletu informacji w miejscu, do którego zespół zagląda rutynowo, znacząco zwiększa szansę na ich wykorzystanie i refleksję nad tym, jakie wnioski z nich płyną. Osobna baza i narzędzia BI’owe Ostatnią z opcji w kontekście narzędziowego mierzenia i prezentowania przewidywalności są narzędzia BI. Najczęściej źródłem danych była JIRA, Azure DevOps lub podobne narzędzia służące do zarządzania zadaniami. Surowe dane z tych narzędzi można przesłać do systemów BI. Niezależnie, czy będzie to Power BI, Tableau czy inne narzędzie, zależnie od tego, co jest używane w danej organizacji. Różne narzędzia mają różny poziom popularności w zależności od organizacji. Oczywiście wymaga to już określonych kompetencji, zarówno w zakresie podłączenia danych, jak i konfiguracji raportów. W zamian można otrzymać atrakcyjną formę wizualizacji, możliwość konfigurowania dodatkowych filtrów lub rozszerzania zakresu danych. W przypadku dużych organizacji dużą wartością może być możliwość pokazania na jednym dashboardzie wyników wielu zespołów lub pewna forma standaryzacji np. dotycząca sposobu mierzenia przewidywalności. Potencjalna nagroda jest duża, ale wiąże się to również z określonym kosztem. Jeżeli zespół dysponuje odpowiednimi kompetencjami, koszt może być pomijalny, a w niektórych przypadkach warto ponieść ten wysiłek, aby uzyskać wartościowe raporty i miarodajne wizualizacje. Wskazówki na temat stosowania miary przewidywalności Uwzględnij stopień innowacyjności zespołu Warto rozpocząć od uwzględnienia stopnia innowacyjności zespołu. W typowym zespole wytwórczym przewidywalność powinna być mierzona. Jest to również pożądana cecha takiego zespołu. W praktyce można jednak wskazać zespoły o bardzo wysokim poziomie innowacyjności, których praca opiera się głównie na badaniach, odkrywaniu i działaniach typu research and development a poziom innowacyjności tych zespołów jest wyjątkowo wysoki. Ze względu na złożoność i nieprzewidywalność zadań badawczych, takie zespoły z natury rzeczy mogą mieć trudność z osiąganiem przewidywalności, w rozumieniu prezentowanym artykule. W takich przypadkach należy przyjąć pewną poprawkę, swego rodzaju gwiazdkę przy tej miarze. W niektórych organizacjach część zespołów może być z definicji nieprzewidywa

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 Spis treści Problem z dobrym zrozumieniem celu projektuPresja biznesu na wdrożenie całościWyważenie perspektywy technologii i biznesu przy podzialeCzasochłonność procesu dzieleniaMentalność „Niech ktoś podzieli”FAQ: Wyzwania w dzieleniu projektów na mniejsze częściTranskrypcja podcastu „Wyzwania w dzieleniu projektów na mniejsze części„ Problem z dobrym zrozumieniem celu projektu Naszym zdaniem jest to częsty bloker, który sprawia, że bardzo trudno przystąpić do sensownego podziału projektu czy inicjatywy, jeżeli tak naprawdę nie rozumiemy, co chcemy uzyskać. Oczywiście, bez zrozumienia celu możemy mechanicznie spróbować podzielić projekt na mniejsze części, ale prawdziwa różnica pojawia się wtedy, gdy bardzo dobrze rozumiemy cel. W takiej sytuacji otwierają się możliwości zrealizowania pewnych rzeczy w znacznie mądrzejszy sposób, zamiast patrzeć na projekt bez zrozumienia, co tak naprawdę chcielibyśmy tym projektem uzyskać. Zrozumienie celu jest tutaj fundamentalnym wstępem do dobrego podziału, dlatego pierwsza porada może wydawać się oczywista. 1. Zapewnij, że cel jest zrozumiały Można to osiągnąć na kilka sposobów. Jednym z nich jest dobre spotkanie typu kick-off, czyli otwarcie inicjatywy, projektu, zmiany produktowej lub kolejnego etapu rozwoju produktu. Nie zakładaj, że inni wiedzą to samo, co ty. Zadbaj o klarowny wstęp, krótkie exposé i odpowiednie wprowadzenie zespołu w dotychczas zebrane informacje oraz kontekst biznesowy, który uzasadnia realizację danego przedsięwzięcia. Takie przygotowania do kick-offu nie pójdą na marne, ponieważ zrozumienie celu można wzmacniać również przez powtarzanie tych informacji. Warto zatem wypracować praktykę regularnego wracania do celu przy każdej nadarzającej się okazji. Mogą to być Przeglądy Sprintów, jeśli stosujesz Scruma, a także demo, spotkania projektowe, warsztaty lub podsumowania prac. Każde z tych miejsc, w których zbiera się zespół lub jego wyraźna część, stanowi okazję do przypomnienia, jaki jest cel i na czym polega istota aktualnie realizowanych działań. Warto przyjąć założenie, że wielokrotne powtarzanie – także w różnych formach – pomoże utrwalić cel i umożliwi jego trwalsze osadzenie w zespole. Dzięki temu, gdy nadejdzie moment związany z podziałem pracy, zarówno na początku, jak i w dalszych etapach, cel będzie pamiętany, łatwy do przywołania i na tyle zrozumiały, że stanie się dla zespołu oczywistością. 2. Używanie sprawdzonych technik wspierających pracę na celach Warto rozważyć takie techniki jak impact mapping, podejście golden circle, product vision board, OKR-y czy opportunity solution tree. Jeśli te nazwy są ci obecnie mało znane, możesz je łatwo wyszukać w internecie. Mamy doświadczenie z większością tych narzędzi i możemy potwierdzić, że nie tylko wspierają zrozumienie, po co realizowane są poszczególne działania, lecz także są zazwyczaj narzędziami wizualnymi. Praca z nimi to nie tylko rozmowa, to również element wizualny, który znacząco poprawia i zwiększa zrozumienie tego, co stanowi istotę danej zmiany. W sytuacji, gdy zespół przygotowuje się do sesji dzielenia, a zespół nie korzystał wcześniej z tych narzędzi, warto sięgnąć po jedno z nich jako rozgrzewkę lub wstęp. Jeśli zespół pracował z nimi wcześniej, dobrze wrócić do nich na początku sesji. 3. Sprawdzenie zrozumienia – na przykład parafraza przez uczestników Trzecia praktyka polega na jak najczęstszym sprawdzaniu, czy zespół rozumie cel. Nie tylko osoba zarządzająca projektem, lider produktu czy manager zespołu może komunikować cel, bo możesz poprosić uczestników, aby w formie ćwiczenia lub krótkiej wypowiedzi swoimi słowami opisali, jaki jest cel danej inicjatywy. Dzięki temu sprawdzisz, czy cel jest zrozumiały, a jednocześnie wprowadzisz element, który aktywizuje lub rozgrzewa zespół, i wykorzystasz różnorodność zespołu, różne perspektywy i specjalizacje, dzięki którym uczestnicy patrzą na sprawy w inny sposób. Parafraza celu lub próba jego opisania z różnych perspektyw poprawia jakość zrozumienia. Dlatego regularnie sprawdzaj zrozumienie, na przykład prosząc osoby z zespołu o parafrazę celu. Presja biznesu na wdrożenie całości Mamy na myśli wdrożenie całego projektu, całego zakresu, całej inicjatywy albo czasami pełnej funkcji w produkcie. Taka sytuacja może wywołać niechęć lub poczucie bezsensu dzielenia pracy. Pojawia się wtedy pytanie: po co dzielić, skoro na końcu i tak trzeba wdrożyć całość zgodnie z pierwotną definicją, a presja biznesu lub managementu może wywołać wrażenie, że podzielenie pracy to proszenie się o kłopoty, bo strona wywierająca presję może uznać, że zespół próbuje wycofać się z części zakresu. To może wywołać różne negatywne emocje i sprawić, że zespół nie chce podjąć się dzielenia pracy. 1. Pokazanie korzyści, które wynikają z dekompozycji na wczesnym etapie Warto założyć, że nie wszyscy znają te korzyści ani ich wcześniej nie doświadczyli. Mamy na myśli przede wszystkim wczesne ograniczanie ryzyk biznesowych. Dzięki temu możesz wcześniej sprawdzić, czy proponowane rozwiązanie odpowiada na potrzebę rynkową i czy jest poprawnie zaprojektowane. Możesz również ograniczyć ryzyka technologiczne, na przykład upewniając się, że zespół potrafi pracować z wybraną technologią. A także ryzyka społeczne, czy osoby odpowiedzialne za implementację potrafią ze sobą skutecznie współpracować. Ryzyka to jedna strona tej sytuacji, a druga strona dotyczy dostarczenia najważniejszej wartości, esencji zmiany, możliwie jak najwcześniej. 2. Zrozumienie obaw interesariuszy, które blokują ich przed podziałem Warto uruchomić empatię i wczuć się w perspektywę interesariuszy. To, co z perspektywy zespołu wykonawczego wygląda jak niezrozumiała albo nawet nieracjonalna presja, może wynikać z unikalnych doświadczeń konkretnej osoby, managera lub grupy w organizacji. Możesz tego nie dostrzegać, a mimo to warto to uwzględnić. Co to oznacza w praktyce? Odniesiemy się do przykładu z jednej z firm, z którą współpracowaliśmy. Zespół odpowiedzialny za operacje, na przykład za działania posprzedażowe i obsługę klienta, obawiał się, że ich narzędzia zostaną uznane za nieistotne albo w ogóle nie powstaną w ramach projektu, dlatego podchodzili do negocjacji twardo i sceptycznie oraz nie chcieli dzielić zgłoszonych wymagań czy potrzeb narzędziowych. Wynikało to z doświadczeń z poprzednich projektów, w których pod presją czasu narzędzia dla nich w ogóle nie powstawały, a zespół musiał obsługiwać klientów za pomocą Excela i ręcznie pisanych maili, ponieważ system nie obejmował ich potrzeb, mimo że pierwotnie był tak planowany. Dlatego warto uwzględnić tę perspektywę i zrozumieć obawy interesariuszy. Innym przykładem obawy jest sytuacja, w której ktoś obiecał komuś bardzo precyzyjny i często rozbudowany zakres. Często te osoby nie mówią o tym wprost albo trudno im przyznać, że złożyły taką obietnicę, dlatego z oporem podchodzą do pomysłu podzielenia tej całości na mniejsze części. Obawiają się, że podział może stać się pretekstem do usunięcia części zakresu. W części organizacji pojawia się pęd do realizowania dużych i spektakularnych projektów. W takim kontekście idea dzielenia może wydawać się sprzeczna z tym podejściem. Wynika to z potrzeby tworzenia dużych projektów strategicznych, spektakularnych premier oraz zdobywania nagród za przełomowe odkrycia lub innowacje. Warto uwzględnić tę perspektywę, bo ktoś może przygotowywać się na konferencję dotyczącą innowacji w bankowości i chce opowiedzieć na scenie o dużych, efektownych planach, na przykład o nowych implementacjach opartych na AI. To nie oznacza, że spektakularnych projektów nie da się podzielić, ale warto uwzględnić kontekst i zadbać o komunikację, ponieważ jedno nie wyklucza drugiego. W najgorszym razie wdrożenie może odbyć się jako spektakularna premiera, ale wciąż warto dzielić pracę wcześniej i dostarczać ją etapami, nawet jeśli część rezultatów nie trafi od razu do publikacji. 3. Przepracowanie z biznesem różnicy między podziałem na części a obietnicą realizacji całości W skrócie: podział pracy na mniejsze części nie oznacza automatycznie rezygnacji z wdrożenia całości. Jednocześnie widzimy tu pewną kontrowersję, bo możesz mieć doświadczenia z obecnej lub poprzednich firm, w których podział pracy prowadził do wdrożenia tylko części rozwiązania z powodu ograniczeń czasowych. Zdarza się, że ta część jest satysfakcjonująca, a elementy, których nie udało się zrobić wcześniej, nie trafiają już do realizacji, bo organizacja przechodzi do kolejnych koncepcji. W założeniu nie musi to wyglądać w ten sposób, ale rozumiemy, że wcześniejsze doświadczenia mogą skłaniać do ostrożnego podejścia do tej porady. W szczegółach pojawia się druga kontrowersja – koncepcja potrzebnej całości. Może się okazać, że ktoś kurczowo trzyma się wyobrażenia całości zakresu lub rozwiązania, które powstało na bardzo wczesnym etapie. Czasami niektórzy trzymają się tej wizji, zakładając, że od początku wiedzieli, czego potrzeba, i że cały pierwotny zakres odpowiada dokładnie na potrzeby rynku lub klienta. To prowadzi z powrotem do kwestii ryzyk biznesowych. Zbyt wiele decyzji podjętych na zbyt wczesnym etapie może tworzyć złudzenie, że wiadomo, czego naprawdę potrzeba. To dlatego ta rada wiąże się z podwójną kontrowersją, ale na bardzo wczesnym etapie bardziej dyplomatyczne może być stwierdzenie: „Podzielimy na kawałki i wdrożymy to, co okaże się potrzebną całością”, przy jednoczesnym założeniu, że potrzebna całość nie musi oznaczać pełnego zakresu ro

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 i blokadę powiadomień.  Dowiesz się, jak przestać rozgrzebywać milion zadań, jak utrzymać skupienie i jak stworzyć sobie przestrzeń, w której naprawdę da się pracować. To solidny zastrzyk inspiracji dla każdego, kto chce pracować mądrzej, a nie więcej. Porządny Agile · Praktyki wspierające produktywność osobistą Spis treści Lista rzeczy do zrobieniaPlanowanie dnia Dzielenie pracy na małe kawałki Skupienie na jednej rzeczy na raz Łączenie pracy w paczkiTechnika Pomodoro Regularne przerwy Izolacja od dźwięku otoczenia Blokada stron niezwiązanych z pracą Blokada połączeń i powiadomień Organizacja przestrzeni do pracyFAQ: Praktyki wspierające produktywność osobistąTranskrypcja podcastu „Praktyki wspierające produktywność osobistą„ Lista rzeczy do zrobienia Zacznijmy od pierwszej praktyki, listy rzeczy do zrobienia. Co właściwie się za nią kryje? To praktyka inspirowana metodą Getting Things Done. Jej celem jest ograniczenie rozproszenia poprzez przeniesienie wszystkich zadań z głowy na najlepiej konkretną, fizyczną lub elektroniczną listę rzeczy do zrobienia. Im bardziej rozproszona jest praca i im więcej wątków trzeba ogarniać równocześnie, tym łatwiej coś umyka. Zadania potrafią przypominać o sobie w losowych momentach. Takie sytuacje frustrują, stresują i często powodują przerwanie aktualnego zadania, by zająć się czymś zupełnie innym. Im bardziej zróżnicowane są zadania i wątki, tym większe ryzyko zapominania o części z nich. Niezapisane sprawy potrafią przypomnieć o sobie w zupełnie przypadkowych momentach. Niespodziewane przypomnienia wywołują stres, frustrację i często prowadzą do przerwania bieżącej pracy, by zająć się czymś innym. Regularne korzystanie z list rzeczy do zrobienia pozwala ograniczyć stres i odzyskać spokój. Zamiast nosić wszystkie zadania w pamięci, wystarczy zapisać je na liście i wrócić do nich w odpowiednim momencie. Warto prowadzić kilka oddzielnych list, osobno dla spraw zawodowych, domowych czy prywatnych. Dzięki temu można sięgać po konkretne zadania wtedy, gdy przychodzi na nie czas, a jednocześnie uniknąć niechcianych przypomnień w nieodpowiednich momentach. Dzięki takiemu podejściu nie zdarza się już sytuacja, w której podczas pełnego skupienia, na przykład w trakcie prezentacji, nagle przypomina się o konieczności wysłania oferty lub odpowiedzi na wiadomość. Książkę, na której oparto tę metodę, przeczytaliśmy wiele lat temu. Już wtedy było widać, że wymaga aktualizacji. Część treści powtarzała się, a autor omawiał je kilkakrotnie w różnej formie. Mimo to sama koncepcja nadal ma wartość i zastosowanie. Kluczowym elementem metody jest tzw. Trusted System – jedno zaufane miejsce, w którym można zapisać wszystko, co wymaga uwagi, z pewnością, że nic nie zaginie. Wspomniane wcześniej nagłe przypomnienia o zadaniach w trakcie pracy to zjawisko dobrze znane. W takich sytuacjach warto natychmiast zanotować myśl w zaufanym systemie, na przykład w aplikacji do zarządzania zadaniami  i wrócić do bieżącego zajęcia. Wystarczy kilka sekund, by uniknąć utraty koncentracji i mieć pewność, że nic istotnego nie umknie. W kontekście produktywności warto dodać, że wiele z praktyk omawianych w tym materiale dotyczy umiejętności utrzymania skupienia i doprowadzania zadań do końca. Jednym z najtrudniejszych rodzajów rozproszenia jest tzw. pętla niekończącego się myślenia o zadaniach, ciągłe przypominanie sobie o nich zamiast faktycznego działania.  Planowanie dnia  Sama lista rzeczy do zrobienia jest pomocna, ale kluczowym krokiem jest jej codzienne przejrzenie i świadome zaplanowanie, które z zadań warto, trzeba lub chce się zrealizować danego dnia. Istnieją różne podejścia do momentu, w którym najlepiej zaplanować dzień. Najczęściej planujemy w jednym z dwóch momentów, wieczorem, z myślą o kolejnym dniu, lub rano, tuż przed rozpoczęciem pracy. Zanim rozpoczniesz pracę, przejrzyj listę zadań i określ, co powinno lub może zostać wykonane danego dnia. Wystarczy poświęcić na to od 5 do 15 minut, by rozpocząć dzień z jasnym planem i pewnością, że żadne istotne zadanie nie zostało pominięte. Ta praktyka łączy się nie tylko z produktywnością, lecz także z ogólną efektywnością osobistą. Przeglądając plan dnia, najlepiej rano, warto ocenić, które zadania są najbardziej wartościowe i realne do wykonania w danym dniu. Celem jest skupienie się na działaniach, które przyniosą największy efekt. Niektóre zadania mogą poczekać, inne mają charakter czysto życzeniowy. To właśnie moment, by podejść do planowania realistycznie i codziennie rano zastanowić się, co rzeczywiście da się wykonać i co będzie najbardziej wartościowe. Warto określić, które z tych działań stanowi priorytet lub najważniejszy punkt dnia. W pracy w metodyce Scrum można to połączyć z koncepcją celu dnia. To konkretne zadanie lub rezultat, który ma być kluczowym osiągnięciem dnia. W ten sposób wcześniejsza praktyka, lista rzeczy do zrobienia, staje się naturalnym źródłem pomysłów na to, jak zaplanować dzień i jakie działania wybrać jako priorytetowe. Dzielenie pracy na małe kawałki  Jednym z powodów odkładania pracy lub utknięcia w zadaniach jest ich zbyt duża skala. Próba realizacji zadań o zbyt szerokim zakresie często prowadzi do przeciążenia i braku postępów. Samo wyobrażenie dużego, złożonego zadania może wywoływać zniechęcenie, obawę przed porażką czy poczucie przeciążenia. W efekcie prowadzi to do odwlekania działania lub rozpoczęcia pracy bez realnego postępu. Mogą to być nawet drobne, pojedyncze czynności. Dobrym przykładem jest przygotowanie prezentacji. Przykładowo, przygotowanie godzinnej prezentacji inspiracyjnej można rozłożyć na kilka etapów: wymyślenie tematu, zapisanie pierwszych notatek, utworzenie pliku i podstawowego szkieletu prezentacji (np. strona tytułowa, wstęp, zakończenie). Każdy slajd może stanowić osobne zadanie, podobnie jak końcowy przegląd całej prezentacji. W połączeniu z listą rzeczy do zrobienia takie podejście sprzyja skupieniu. Duże, skomplikowane projekty przekształcają się w serię drobnych, wykonalnych zadań, które można realizować etapami, w dogodnym tempie, dziś, jutro lub wtedy, gdy pojawi się przestrzeń i energia. Ważnym elementem dzielenia pracy na małe części jest poczucie postępu. Wykonanie nawet drobnego zadania daje szybką nagrodę, satysfakcję z odhaczenia pozycji na liście. W aplikacjach często towarzyszy temu dźwięk lub animacja, które wzmacniają to pozytywne wrażenie. To prosty, ale skuteczny mechanizm psychologiczny motywujący do dalszego działania. Dzielenie pracy na mniejsze elementy ma też wymiar praktyczny – pomaga doprecyzować, co właściwie należy zrobić. W trakcie tego procesu pojawiają się różne możliwe ścieżki realizacji: proste i szybkie, pośrednie lub bardziej rozbudowane. To moment, w którym można ocenić, która z nich najlepiej pasuje do sytuacji. Wybór ścieżki zależy od czasu, dostępnej energii i nastawienia do tematu. Warto rozbić zadanie na krótkie, łatwe do wykonania kroki, które nie budzą oporu przed rozpoczęciem. Kluczowa jest świadomość, że każdy z nich można zrealizować w kilkanaście minut. W tym miejscu działa prosta zasada: gdy już zaczynasz, łatwiej jest kontynuować. Dlatego wykonywanie zadań małymi krokami to skuteczny sposób na przełamanie oporu przed rozpoczęciem pracy. Dzięki temu praca stopniowo się posuwa, a lista zadań realnie się skraca. Istnieje też dodatkowy efekt uboczny dzielenia pracy, po rozbiciu zadania można zauważyć, że niektóre jego elementy mają większą wartość, a inne są całkowicie zbędne. Warto to świadomie dostrzec już na wczesnym etapie pracy, uporządkować i zdecydować, z których elementów lepiej zrezygnować, szczególnie z tych, które wymagają czasu, a nie wnoszą realnej wartości dodanej, niezależnie od tego, jak jest ona definiowana. Przykładowo, przy przygotowywaniu prezentacji można świadomie pominąć niektóre elementy, jak notatki dla prelegenta. Choć wydają się przydatne, w praktyce często nie wnoszą istotnej wartości, dlatego ich pominięcie pozwala zaoszczędzić czas i skupić się na ważniejszych aspektach. Skupienie na jednej rzeczy na raz  Kolejną skuteczną praktyką jest skupienie się na jednej rzeczy. Jej istota polega na konsekwentnym realizowaniu jednego konkretnego zadania od początku do końca, bez równoległego podejmowania innych działań. Nawet jeśli pojawiają się drobne przerwy lub nowe zadania, warto świadomie wracać do pierwotnego tematu, aby uniknąć jego rozciągania w czasie i utraty koncentracji. Po pierwsze, zbyt długie przerwy prowadzą do utraty skupienia, mimo że istniał konkretny powód rozpoczęcia pracy nad danym zadaniem. Po drugie, każde rozproszenie wydłuża całkowity czas realizacji. Choć nie poświęca się wtedy pracy nad zadaniem, jego „cykl życia” procesowo się wydłuża. Realizowanie zadań z przerwami, w kilku podejściach, generuje coraz wyższy koszt czasowy i poznawczy. W efekcie coś, co mogło zająć kilka minut, trwa kilkakrotnie dłużej, ponieważ każde ponowne wejście w zadanie wymaga ponownego „rozruchu” uwagi. Warto ćwiczyć umiejętność utrzymywania skupienia. Częstą pokusą jest podążanie za kolejnymi ciekawymi wątkami, np. otwieranie nowych kart, czytanie artykułów lub analizowanie tematów niezwiązanych z bieżącym zadaniem. Dlatego warto przyjąć zasadę świadomego skupienia, zobowiązania wobec siebie, by doprowadzić rozpoczęte zadanie do końca, odhaczyć je na liście i dopiero potem przejść do kolejnego. Domknięcie pracy daje satysfakcję i poczucie postępu. Najlepiej działa rytm pracy, w którym kolejne zadania są realizowane i domykane po jednym. To przeciwieństwo modelu z wieloma rozgrzebanymi tematami, licznymi otwartymi zakładkami, szkicami wiadomości i plikami w edycji, które rozpraszają uwagę i blokują efektywność. Tak jak komputer spowalnia przy zbyt wielu otwartych oknach, tak samo spada wydajność umysłowa, gdy uwa

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ć nowe narzędzie, by nagle wszystko zaczęło działać jak w zegarku? Bierzemy na tapet 7 najczęściej spotykanych mitów o efektywności zespołów. Pokazujemy, dlaczego „więcej” nie zawsze znaczy „lepiej”, czemu brak przestojów to wcale nie złoty Graal i jak nie wpaść w pułapkę myślenia, że narzędzia rozwiążą za nas problemy. Podsuniemy Ci też praktyczne wskazówki – jak rozmawiać o efektywności w firmie i jak odróżniać realne usprawnienia od złudnych obietnic. Porządny Agile · Mity o efektywności zespołów Czym dla nas jest efektywność? Na początek warto wyjaśnić, czym właściwie jest efektywność. Nie chodzi o dokładną definicję, lecz o uporządkowanie pojęć, zanim pojawią się mity. Efektywność zespołu to relacja wartości uzyskanej z jego pracy do kosztu uzyskania danego efektu. Z tak prostego wzoru wynika, że można ją poprawić na dwa sposoby: zwiększając wartość pracy, czyli przy tym samym koszcie dostarczając lepszy efekt, lub zmniejszając koszt wytworzenia efektu, czyli osiągając ten sam rezultat taniej Spis treści Czym dla nas jest efektywność?„Efektywności nie da się mierzy攄Najistotniejsza jest dostarczona wartość, nie ma potrzeby sprawdzać efektywności” „Efektywność moich zespołów wzrośnie, jeśli będą w stanie robić więcej” „Efektywność moich zespołów wzrośnie, jeśli będą w stanie pracować szybciej” „Efektywność moich zespołów wzrośnie, jeśli nie będzie wolnych przebiegów” „Efektywne zespoły pracują nad wieloma tematami jednocześnie”„Nowe narzędzie rozwiąże nasze problemy z efektywnością” FAQ: Mity o efektywności zespołówTranskrypcja podcastu „Mity o efektywności zespołów„ Przejdźmy do mitów i uproszczeń dotyczących efektywności. Będzie ich siedem, a każdy zostanie przedstawiony w formie cytatu. Część z nich to autentyczne wypowiedzi, które naprawdę padły, inne to lekkie uogólnienia, ale łatwo wyobrazić sobie, że mogłyby zostać wypowiedziane w podobny sposób.  „Efektywności nie da się mierzyć” To przekonanie pojawia się wyjątkowo często. Zazwyczaj wynika z braku refleksji lub praktycznego doświadczenia w tym obszarze. Osoba, która tak twierdzi, nie ma jasnego obrazu, czym efektywność naprawdę jest, więc uznaje ją za pojęcie zbyt płynne i nieuchwytne, by można je było zmierzyć. Podobne stwierdzenie często pojawia się ze strony osób zarządzających lub przedstawicieli firm, w których mierzenie wyników jest na niskim poziomie dojrzałości. Jeśli organizacja nie monitoruje jakości, satysfakcji ani innych kluczowych wskaźników, trudno oczekiwać, że będzie potrafiła mierzyć efektywność. W tym przypadku nie ma miejsca na wątpliwości,  efektywność da się zmierzyć. To sytuacja wyjątkowo klarowna. W innych przykładach pojawi się więcej niuansów. Wystarczy znać wartość dostarczoną, wyrazić ją w konkretnej jednostce, podzielić przez koszt wytworzenia i otrzymujemy miarę efektywności. Sam pomiar jest prosty. Trudność pojawia się dopiero wtedy, gdy trzeba odpowiednio wykorzystać jego wynik. „Najistotniejsza jest dostarczona wartość, nie ma potrzeby sprawdzać efektywności”  Osoba, która tak twierdzi, zwykle zakłada, że najważniejsze jest skupienie się na wartości biznesowej i jej maksymalizacji. Taki sposób myślenia można znaleźć choćby w starszej wersji Scrum Guide’a, w definicji roli Product Ownera, gdzie nie kładziono nacisku na pomiar efektywności. Założenie jest proste: jeśli skupimy się wyłącznie na maksymalizacji wartości, efektywność przestaje mieć znaczenie. To przykład sytuacji, w której jedna strona równania efektywności dominuje nad drugą. Jest tu jednak istotny niuans. Dążenie do maksymalizacji wartości jest jednym z najlepszych sposobów na poprawę efektywności, ale nie może być traktowane jako jedyne rozwiązanie. Nie chodzi o to, by stale wybierać tylko działania o najwyższej wartości. Takie podejście ma swoje ograniczenia i może prowadzić do pułapek. Innymi słowy, obie strony równania efektywności mają znaczenie. Nawet jeśli mamy przekonanie lub potwierdzenie, że dostarczana wartość jest satysfakcjonująca, warto sprawdzić jakiego kosztu wymagała. Można łatwo wyobrazić sobie sytuację, w której zespół dostarcza coś rzeczywiście wartościowego, lecz za bardzo wysoką cenę. Po dokładnym przeliczeniu może się okazać, że relacja wartości do kosztu przestaje być korzystna. Na przykład, jeśli coś wartościowego dostarczymy w ciągu trzech miesięcy, koszt może być akceptowalny w stosunku do uzyskanej wartości. Jednak gdy ten sam efekt wymaga dziewięciu miesięcy pracy, proporcja między wartością a kosztem mogłaby okazać się nieakceptowalna. Innymi słowy, koszt uzyskania efektu może przewyższyć wartość, jaką ten efekt wnosi. „Efektywność moich zespołów wzrośnie, jeśli będą w stanie robić więcej”  To przekonanie opiera się na uproszczonym założeniu, że im więcej pracy wykonujemy, tym wyższa jest efektywność. Takie podejście kryje w sobie poważną pułapkę. Skupienie się wyłącznie na ilości wytwarzanej pracy może sprawić, że zabraknie refleksji nad tym, czy to, co powstaje w większej ilości, ma rzeczywistą wartość. Ta pułapka jest wyjątkowo powszechna, zwłaszcza gdy organizacja skupia się na mierzeniu ilości wykonanej pracy, na przykład liczbie zakończonych projektów, dostarczonych story pointów lub trendzie ich wzrostu. Takie wskaźniki mogą być przydatne, jeśli analizuje się je razem z innymi danymi, jednak z perspektywy efektywności bywają mylące. Liczba dostarczonych funkcji nie musi przekładać się na realny rezultat biznesowy, który najłatwiej zmierzyć poprzez dane finansowe, na przykład wzrost przychodu, liczbę nowych rejestracji czy zwiększoną sprzedaż dzięki nowym elementom produktu. Właśnie w tym tkwi główna pułapka. Paradoksalnie efektywność może wzrosnąć, gdy zespoły będą realizować mniej zadań, ale bardziej wartościowych. Można to osiągnąć dzięki lepszej selekcji, właściwemu ustalaniu priorytetów oraz stosowaniu dobrych praktyk Product Discovery, zamiast koncentrować się na nieprzemyślanej pogoni za kolejnym zadaniem. Oczywiście istnieje też sytuacja idealna, w której zespoły robią więcej i jednocześnie to, co robią, ma wysoką wartość. W praktyce jednak nie należy zakładać, że większa liczba zadań zawsze oznacza wyższą efektywność. Może się okazać, że efektywność pozostaje na tym samym poziomie, a nawet spada, jeśli brakuje odpowiedniej selekcji i skupienia na realizacji rzeczy naprawdę wartościowych i przemyślanych. „Efektywność moich zespołów wzrośnie, jeśli będą w stanie pracować szybciej”  Warto rozróżnić te dwa podejścia, wcześniejsze dotyczyło robienia większej ilości pracy, a to odnosi się do tempa jej wykonywania. Można zauważyć trend wynikający z popularności wskaźnika time to market, który przez lata był jednym z kluczowych mierników w transformacjach zwinnych i produktowych. Należy jednak zachować ostrożność. Praca wykonywana szybko tylko po to, by „dowieźć” coś jak najszybciej, może prowadzić do poważnych błędów i spadku jakości. Ostrzegamy przed sytuacją, w której tempo pracy staje się ważniejsze niż jakość. Szybkie działanie bez refleksji nad wartością lub całkowitym kosztem utrzymania rozwiązania może przynieść odwrotny efekt. Często okazuje się, że pominięcie refaktoryzacji czy dbałości o utrzymanie produktu daje krótkotrwałą oszczędność, ale w dłuższej perspektywie powoduje poważne problemy. Może się zdarzyć, że pojedynczy Sprint lub inicjatywa kończy się szybko, ale w dłuższej perspektywie koszty wzrosną. W efekcie efektywność, zwłaszcza długoterminowa, zaczyna spadać. Temat jest złożony, ponieważ istnieją sytuacje, w których szybsze dostarczenie produktu lub nowych funkcji na rynek pozwala zająć pozycję lidera i uzyskać przewagę konkurencyjną. Jednak przekonanie, że szybkie działanie zawsze oznacza efektywność, w dłuższej perspektywie może okazać się pułapką. Szybsze dostarczanie może zwiększyć efektywność, o ile jest stosowane rozważnie. Stały nacisk na tempo pracy „za wszelką cenę” prowadzi jednak często do odwrotnych skutków niż zamierzone. „Efektywność moich zespołów wzrośnie, jeśli nie będzie wolnych przebiegów”  Ten mit opiera się na przekonaniu, że najbardziej efektywne są te zespoły, które są nieustannie zajęte. Zakłada się, że wysoka efektywność oznacza maksymalne obłożenie zadaniami. Często używa się określeń, że zespoły są „doładowane”, „zapakowane po korek” czy „zatankowane do pełna”. Wszystko to sprowadza się do przekonania, że im więcej zadań uda się upchnąć, tym lepiej wykorzystany będzie czas pracy i tym większa będzie efektywność. W takim myśleniu nie ma miejsca na żadną wolną przestrzeń, każdy moment musi być wypełniony zadaniami. Według tej logiki pełne obłożenie pracą oznacza najwyższą efektywność. Teorie dotyczące organizacji pracy jasno wskazują, że to błędne założenie. Efektywność zespołów spada, gdy nie mają żadnej przestrzeni na wolniejsze przebiegi. To zjawisko jest nieuniknione. Potwierdza to między innymi teoria kolejek, zgodnie z którą pełne obłożenie prowadzi do powstawania długich kolejek, a te generują dodatkowe koszty i opóźnienia, które wzajemnie się nasilają.  Drugi aspekt dotyczy psychologii zarządzania i motywacji. Przeładowanie zadaniami obniża efektywność pracy poszczególnych osób. Osoba zbyt mocno obciążona zadaniami kreatywnymi wykonuje je z mniejszą jakością. Dodatkowo realizuje je wolniej, co niweluje ewentualny efekt „szybszego dostarczania”. W rezultacie przeładowane zespoły dostarczają wolniej, a każde zadanie wykonywane jest dłużej i drożej. Szczególnie niebezpieczna jest presja menedżerów, Product Ownera czy zarządów, by nie pozostawiać żadnej przestrzeni,  żadnego luzu czy marginesu w pracy zespołów. Przeładowanie planów, zarówno na poziomie kwartału czy projektu, jak i pojedynczego Sprintu, jest zjawiskiem wyjątkowo groźnym, ponieważ trudno je później skorygować. Z perspektywy menedżerskiej warto unikać takiego przeciążania i raczej zachęcać do tworzenia przestrzeni w planac

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 – często przejmując ich nawyki, niekoniecznie te najlepsze i aktualne. Z czasem prowadzi to do sytuacji, w której każdy pracuje „po swojemu”, a efektywność zespołu spada. Opowiadamy o typowych błędnych założeniach, które przyspieszają ten proces, oraz pokazujemy praktyczne sposoby na zatrzymanie erozji wiedzy. Dowiesz się, jak sprawić, by szkolenia były tylko początkiem, a realny rozwój trwał w codziennej pracy Twojego zespołu. Porządny Agile · Powolna erozja efektow szkoleniowych Zdefiniowanie zjawiska Większość zespołów, zwłaszcza tych pracujących dłużej w podobnym składzie, wypracowuje własną kombinację praktyk. Część z nich wspiera efektywność, ale część działań wręcz ją ogranicza. Nie są to praktyki opisane w książkach ani zgodne z modelem, teorią czy popularnym podejściem. Nie stanowią też świadomej i korzystnej ewolucji istniejących metod. To raczej lokalne modyfikacje, często niezamierzone i nieuświadomione, które sprawiają, że zespół wykonuje pewne działania, lecz nie czerpie z nich korzyści ani w pierwotnej formie, ani w nowej wersji. Spis treści Zdefiniowanie zjawiskaJakie założenia mogą prowadzić do erozji efektów szkoleniowych?Jak rozpoznać, że problem erozji wiedzy dotyczy twojego obszaru?Co zrobić, żeby przezwyciężyć erozję wiedzy i umiejętności?FAQ: Powolna erozja efektów szkoleniowychTranskrypcja podcastu „Powolna erozja efektów szkoleniowych” Oto przykład z praktyki. Jeden z zespołów potraktował koncepcję Backlogu Produktu w uproszczony sposób: po zakończeniu zadania każdy wybierał kolejne działanie według własnego uznania. W efekcie członkowie skupiali się na tematach, które wydawały się sensowne w danym momencie, pomijając fakt, że Backlog Produktu powinien być uporządkowany. Najważniejsze elementy muszą znajdować się na jego górze i to właśnie na nich zespół powinien koncentrować się w pierwszej kolejności. Kolejny przykład związany jest z retrospektywą. Kilka lat temu jeden z zespołów, wcześniej uczestniczący w szkoleniu z podstaw Scruma, poprosił o wsparcie. Zespół dobrze współpracował i rozwijał się, a po pewnym czasie poprosił o dodatkowe wsparcie. Niezależnie od szczegółów, ciekawą obserwacją było przyjęcie przez zespół założenia, iż Retrospektywa służy wyłącznie rozmowom o relacjach w zespole. Wpływ na to miało podejście ówczesnego Scrum Mastera, który koncentrował się głównie na tym obszarze, jednak równocześnie pojawiła się potrzeba usprawnienia procesu wytwórczego w obszarze standardów kodowania i narzędzi używanych przez deweloperów. Początkowo trudno było zrozumieć, dlaczego zespół nie wykorzystywał do tego Retrospektywy, dopóki nie okazało się, że format spotkań koncentrował się wyłącznie na relacjach, komunikacji i emocjach. W efekcie w tej niezamierzonej modyfikacji zabrakło przestrzeni na rozmowę deweloperów o standardach kodowania i sposobach pracy. Chcemy zwrócić uwagę na degradację i erozję praktyk prowadzącą do sytuacji, w której z pierwotnych metod pozostają jedynie szczątkowe elementy, które nie zapewniają efektu, na jaki początkowo liczono. Jakie założenia mogą prowadzić do erozji efektów szkoleniowych? Poniżej znajdziesz przykłady takich założeń – to nie jest pełna lista, ale możesz potraktować ją jako listę do autorefleksji, swoistą checklistę. Zastanów się, czy w Twoim zespole albo w obszarze, którym zarządzasz, takie założenia mogą występować, a także, czy czasem nie pojawiają się one w Twoim własnym myśleniu. 1. Szkolenie to jednorazowy zastrzyk wiedzy dla danego zespołu Skoro raz przerobiono materiał – na przykład trzy lata temu – pojawia się przekonanie, że to wystarczy, nie ma potrzeby do niego wracać, bo treści są opanowane, wykorzystywane w praktyce i temat został zamknięty. 2. Wiedza na dany temat jest powszechna Zakłada się, że każdy nowy członek zespołu lub osoba, która przenosi się pomiędzy zespołami w większej firmie rozumie pojęcia w taki sam sposób jak osoby już obecne w zespole lub ci, którzy wcześniej odbyli szkolenie w odpowiednim formacie. 3. Pewne koncepty są oczywiste i nie trzeba już ich tłumaczyć Trzecie założenie opiera się na przekonaniu, że pewne koncepcje są oczywiste i nie wymagają tłumaczenia. To punkt podobny do poprzedniego, choć różni się źródłem. W tym przypadku chodzi o tzw. klątwę wiedzy: doświadczeni pracownicy i menedżerowie zapominają, jak to jest czegoś nie wiedzieć. Przyjmują, że określone koncepcje są oczywiste dla każdego, a w konsekwencji nie dostrzegają potrzeby ich ponownego wyjaśniania ani organizowania dedykowanych szkoleń. 4. Pracownicy nauczą się „w boju” od doświadczonych osób Czwarte założenie zakłada, że pracownicy nauczą się w praktyce od bardziej doświadczonych osób. Oparte jest ono na przekonaniu o pewnej sekwencji zdarzeń. Dzięki temu poprawiono proces, a nowi członkowie, dołączając do usprawnionego środowiska – mają rzekomo uczyć się wyłącznie poprzez praktykę, co prowadzi do wniosku, że nie potrzebują teorii ani dodatkowych szkoleń. Zakłada się, że mechanizm ten będzie samonapędzający, niczym efekt „perpetuum mobile”. Każda nowa osoba ma uczyć się od poprzedników, co rzekomo eliminuje konieczność organizowania szkoleń. 5. Nie ma budżetów na powtórne szkolenia z tego samego Kolejnym powodem degradacji efektów szkoleniowych jest brak budżetów na ponowne szkolenia z tego samego obszaru. To proza życia – firmy często nie inwestują wystarczająco w rozwój pracowników. A jeśli raz przeznaczono środki na dane zagadnienie, trudno jest uzyskać nowy budżet po kilku latach na ten sam temat. Uznaje się bowiem, że to temat zamknięty. Szczególnie trudne staje się to wtedy, gdy pojawiają się nowe trendy i modne praktyki, które  zdaniem zarządzających, lepiej uzasadniają wydatki i wydają się ważniejsze. Przykładem może być zagadnienie sztucznej inteligencji, które dotyka dziś niemal wszystkich. To obszar, który może wypierać inne ważne tematy, istotne dla Twojego zespołu i Twojej pracy. 6. Szkolenia nic nie dają Ostatnie założenie zakłada, że szkolenia nic nie dają. Źródłem tego przekonania bywają złe doświadczenia z wcześniejszych szkoleń lub programów rozwojowych, szczególnie jeśli miały one charakter masowy albo dotyczyły wyłącznie podstaw, kierowanych do osób początkujących. Z takich szkoleń zespoły mogły niewiele wynieść, a menedżerowie otrzymali negatywną informację zwrotną i nie chcą powtarzać tego formatu. Szczególnie gdy szkolenia dotyczyły rytuałów, konkretnych narzędzi lub rozwiązań niedopasowanych do kontekstu organizacji czy zespołu, można zrozumieć niechęć i świadome nastawienie do unikania takich działań. Problem pojawia się wtedy, gdy nie organizuje się ani takich, ani żadnych innych szkoleń, a erozja efektów postępuje i nie jest równoważona. Istnieją jednak fundamentalne zasady, a także praktyki i umiejętności, które każda firma powinna rozwijać i cyklicznie podtrzymywać. Nie chodzi tu o samą deklarację zwinności. Kluczowe są takie elementy jak efektywność działań, przewidywalność, jakość dostarczanych rezultatów oraz koncentracja na tym, by faktycznie dostarczać wartość odbiorcy. Warto więc zadać sobie pytanie, czy te fundamentalne aspekty są właściwie prowadzone. Jak rozpoznać, że problem erozji wiedzy dotyczy twojego obszaru? Przedstawiamy kilka praktyk, możesz wykorzystać jedną lub kilka z nich. Warto jednak rozważyć wszystkie, które zostaną wymienione, ponieważ razem tworzą spójny program do przeanalizowania sytuacji w Twoim obszarze. 1. Zmierz efektywność zespołów W wielu zespołach mówi się o efektywności, a w wielu firmach oczekuje się od zarządzających jej poprawy. Problem w codziennej praktyce polega na tym, że często trudno jest tę efektywność precyzyjnie zdefiniować i zmierzyć. Dlatego warto jasno określić miarę efektywności dla swojego zespołu, zmierzyć ją i sprawdzić wyniki. To, czy efektywność jest satysfakcjonująca, może stać się kluczowym punktem w dalszej dyskusji o tym, co należy zrobić, aby zmienić sposób działania zespołu lub obszaru. 2. Prześledź wyniki miar procesu wytwórczego W dobrze zorganizowanych procesach wytwórczych stosuje się opomiarowanie, co pozwala ocenić ich kondycję na podstawie konkretnych wskaźników. Mogą się one różnić w zależności od organizacji. Jeśli jednak pojawiają się niepokojące trendy w tych wskaźnikach albo od dawna utrzymują się na niskim poziomie, może to oznaczać, że np. niski wskaźnik jakościowy wskazuje na stopniową utratę kompetencji lub umiejętności związanych z zapewnieniem jakości w zespole. 3. Przeanalizuj proces od strony dostarczania wartości Chodzi o przyjrzenie się procesowi wytwórczemu lub szerzej – procesowi tworzenia i rozwoju produktu. Należy ocenić, które kroki budują wartość, a które jej nie tworzą. Celem jest refleksja nad całością procesu, bez wskazywania pojedynczych praktyk. Zastanów się, gdzie w procesie występuje marnotrawstwo, przestoje lub opóźnienia, a także które punkty zapalne utrudniają pracę i powodują, że proces nie działa sprawnie. Taka analiza ma częściowo charakter ekspercki i jakościowy, ale może dostarczyć cennych wniosków. Dzięki niej możesz zidentyfikować miejsca, w których proces nie funkcjonuje prawidłowo, co często wiąże się z praktykami i wiedzą członków zespołu, którym zarządzasz. 4. Sprawdź satysfakcję ze współpracy u interesariuszy Warto ocenić, czy osoby będące odbiorcami rezultatów lub zainteresowane ich efektami są zadowolone i uważają, że rezultaty procesu wytwórczego mają odpowiednią jakość. Jeśli nie, może to oznaczać, że w zespole pozostały luki kompetencyjne. W takiej sytuacji osoby oceniające efekty pracy mogą dostrzegać coraz więcej niedociągnięć. 5. Spytaj obecnych i odchodzących pracowników o ich rozwój Poprzednia wskazówka dotyczyła otoczenia zespołu, ta skupia się na jego wnętrzu. Brzmi: spytaj obecnych i odchodzących pracowników o rozwój. Porozmawiaj z wybranymi lub wszystkimi członkami zes

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. Wyjaśniamy jak wprowadzać je mądrze i  dlaczego ich mierzenie jest szansą na rozwój i lepszą współpracę w zespole. Jak zawsze wplatamy przykłady z życia i historie zawodowe, by lepiej przedstawić temat. Porządny Agile · Rekomendowane miary dostarczania produktu Spis treści Dlaczego mierzenie procesu jest ważne?Sześć rekomendowanych miar procesu dostarczaniaJak wykorzystać miary procesu dostarczania w praktyce?Rekomendowane miary dostarczania produktu – podsumowanieFAQ: Rekomendowane miary dostarczania produktu📄Transkrypcja podcastu „Rekomendowane miary dostarczania produktu” Dlaczego mierzenie procesu jest ważne? Mierzenie procesu pozwala lepiej zrozumieć jego kondycję. Opinie, odczucia i wyobrażenia są z natury subiektywne. W tym artykule chcemy zwrócić uwagę na to, by opierać się na możliwie konkretnych i obiektywnych danych. Mierzenie procesu umożliwia również lepsze planowanie, prognozowanie i zwiększa przewidywalność pracy zespołu. W zależności od roli w zespole można samodzielnie planować, wspólnie prognozować działania lub pracować w strukturze, w której zespoły bazują na faktach i konkretnych danych. Takie plany da się zweryfikować, sprawdzają się co najmniej w większym przybliżeniu. Choć zawsze istnieje pewien margines nieprzewidywalności, to pomierzony proces z zasady cechuje się większą przewidywalnością niż opieranie się na subiektywnych opiniach czy przeczuciach. Mierzenie procesu umożliwia też weryfikację tempa realizacji strategii produktowej. W większości organizacji istnieją pewne plany, które powinny zostać zrealizowane. Znajomość rzeczywistego przebiegu procesu pozwala zestawić te dane z aspiracjami firmy. Pozwoli też ocenić, czy przy obecnej kondycji procesu oczekiwania dotyczące efektów za miesiąc czy trzy miesiące są w ogóle realne. Mierzenie procesu wspiera budowanie zaufania u interesariuszy i klientów. Jeśli wcześniejsze plany są realizowane, a informacje o procesie, jego przebiegu, typowych stanach czy statystykach, są transparentnie komunikowane, wzmacnia to wiarygodność zespołu. Interesariusze i klienci, niezależnie od tego, kim są, zyskują zrozumienie, możliwość przewidywania i poczucie, że można Wam zaufać. I ostatni argument, którym chcemy się podzielić: miary mogą stanowić punkt odniesienia dla usprawnień procesu w zespole. Część zespołów opiera się na intuicji, rozmawia o możliwych usprawnieniach, ale nie dochodzi do konkretów. Zachęcamy, aby w takich rozmowach pojawiały się twarde dane: konkretne liczby, połączone z oczekiwaniami co do pożądanego stanu. Dzięki temu zespół może opierać refleksję na rzeczywistych, empirycznych informacjach płynących z procesu. Sześć rekomendowanych miar procesu dostarczania 1. Time To Market Definicja Time To Market Time To Market to czas realizacji inicjatywy od momentu pojawienia się pomysłu do chwili, gdy rozwiązanie jest skutecznie wykorzystywane przez klienta końcowego. Liczenie rozpoczyna się w chwili narodzin koncepcji, niezależnie od tego, czy pojawiła się w głowie konkretnej osoby, czy w wyniku pracy większej grupy. Kończy się, gdy przekształcona w funkcję produktową idea zostaje realnie użyta przez użytkownika. Jak mierzyć Time To Market? Najczęściej stosowaną metodą liczenia Time To Market jest średnia krocząca z ostatnich X inicjatyw. Liczba X może wynosić np. 10, ale w przypadku dużych organizacji lub bardzo małych inicjatyw może być znacznie większa. Alternatywnie można obliczyć średnią z określonego okresu np. kwartału, półrocza lub całego roku. Stosowanie średniej kroczącej lub średniej okresowej pozwala zauważyć zmiany w czasie. Zarówno te pozytywne (przyspieszenie realizacji), jak i negatywne, np. spowolnienie procesu. Gdyby natomiast liczyć średnią ze wszystkich inicjatyw od początku istnienia organizacji, zmiany te byłyby niewidoczne. Rozmyłyby się w danych i dawały jedynie nieznaczne wahania „po przecinku”. Time To Market – analogia z życia Będziemy posługiwać się w całym niniejszym materiale analogią wizyty w restauracji. W przypadku Time To Market odpowiada on czasowi od momentu wejścia do restauracji do chwili, gdy klient zje pierwszy kęs zamówionego posiłku. Innymi słowy, od chwili, w której decyduje, że chce coś zjeść w konkretnej restauracji, do momentu, gdy faktycznie otrzymuje i może skosztować zamówione danie. Time To Market – kontrowersje co do sposobu mierzenia Powyższy przykład ma szczególne znaczenie, może być nawet powodem akademickiej dyskusji. Od kiedy właściwie powinno się liczyć Time To Market? Od wejścia do restauracji? A może od zamówienia? Świadomie chcemy zasygnalizować tę potencjalną kontrowersję, bo w praktyce mierzenie Time To Market często budzi wątpliwości. Jednym z kluczowych wyzwań jest precyzyjne określenie momentu rozpoczęcia liczenia. Od kiedy uznaje się, że inicjatywa faktycznie się rozpoczęła? Choć hasło Time To Market jest szeroko wykorzystywane, a wiele firm deklaruje, że je mierzy, jego praktyczna aplikacja bywa problematyczna. Często zdarza się, że moment pojawienia się pomysłu nie jest nigdzie formalnie zarejestrowany. Nie trafił jeszcze do żadnego systemu ani narzędzia. Dodatkowo niektóre zespoły czy organizacje uznają, że liczenie od zbyt wczesnego etapu np. od momentu, gdy pomysł pojawia się w głowie produktowca czy stratega, jest niesprawiedliwe. Dlatego nie chcemy wskazywać jednej właściwej definicji. Warto natomiast być świadomym, że ta popularna miara niesie ze sobą spore kontrowersje. Jej interpretacja ma kluczowe znaczenie dla sposobu, w jaki analizujesz skuteczność działań swojego procesu. 2. Lead Time Lead Time – definicja Na pierwszy rzut oka może wydawać się podobna do Time To Market, jednak między nimi istnieją istotne różnice. Lead Time najczęściej definiuje się jako czas realizacji inicjatywy: od jej formalnego zgłoszenia do momentu wdrożenia. Przez inicjatywę rozumiemy tu większą całość. W klasycznym ujęciu może to być projekt. W środowisku produktowym będzie to pomysł lub okazja biznesowa, często obejmująca zestaw funkcji czy zmian. Miarę tę liczymy od chwili, gdy inicjatywa zostaje uchwycona (zapisana / nazwana /zarejestrowana), aż do momentu, gdy zostaje udostępniona użytkownikom. Lead Time – kontrowersje co do punkt startu mierzenia Także w przypadku Lead Time mogą pojawić się kontrowersje,  szczególnie w kwestii tego, co dokładnie oznacza „zgłoszenie” inicjatywy. Czy chodzi o zapisanie pomysłu w ogólnodostępnym repozytorium, czy o formalne przekazanie go do konkretnego zespołu? Różne organizacje mogą przyjąć odmienne podejścia, dlatego kluczowe jest jednoznaczne zdefiniowanie tego momentu. Jak mierzyć Lead Time? Najczęściej stosuje się średnią kroczącą z ostatnich kilku lub kilkunastu inicjatyw. Ich liczba i rozmiar zależą od specyfiki organizacji. Alternatywnie, można użyć średniej z wszystkich inicjatyw zakończonych w danym okresie, czy w kwartale. Niezależnie od przyjętej metody, świadomie dobierz analizowany przedział czasowy i upewnij się, że dane wykorzystywane do pomiaru są rzetelne. Jakość danych jest wprost zależna od dyscypliny osób korzystających z narzędzi zespołowych. A to przekłada się na wiarygodność wniosków, które można wyciągnąć na podstawie tej miary. W porównaniu z Time To Market – gdzie czas często zaczyna być liczony jeszcze na etapie nieuchwytnego, luźnego pomysłu – Lead Time bazuje zazwyczaj na danych dostępnych w narzędziach zespołu. Czyni to Lead Time miarą łatwiejszą do uporządkowania i bardziej jednoznaczną. Lead Time – analogia z życia Przenieśmy Lead Time na zastosowaną już wyżej analogię restauracyjną. Jego pomiar rozpoczyna się w momencie złożenia zamówienia kelnerowi lub kelnerce, a kończy w chwili, gdy danie zostaje wydane z kuchni. To zakres węższy niż w Time To Market. Ale nadal w wielu restauracjach może zająć trochę czasu. Zawiera w sobie czasy choćby przekazania zamówienia do kuchni albo ewentualne przestoje pomiędzy przekazaniem zamówienia a faktycznym rozpoczęciem przygotowania posiłków. 3. Cycle Time Definicja Cycle Time Cycle Time to czas realizacji inicjatywy liczony od faktycznego rozpoczęcia prac wytwórczych do ich zakończenia. W tym przypadku nie bierze się pod uwagę momentu zgłoszenia inicjatywy ani okresu oczekiwania. Do pomiaru interesujący jest wyłącznie czas przetwarzania, czyli moment rozpoczęcia konkretnych działań mających na celu stworzenie produktu lub funkcji, aż do chwili zakończenia tych działań i przekazania efektu do wdrożenia. W przypadku Cycle Time wyraźnie widać zawężenie zakresu. Obejmuje on przesunięcie zadania do stanu „in progress”, czyli faktyczne rozpoczęcie pracy przez zespół, aż do zakończenia tego zadania po jego stronie. Poza tym etapem mogą występować dalsze czynności, np. weryfikacja lub wdrożenie, które nie są objęte tą miarą. Jak mierzyć Cycle Time? Najczęściej obliczany jest jako średnia krocząca z ostatnich kilku-kilkunastu inicjatyw lub średnia z inicjatyw zakończonych w danym okresie (np. kwartał, półrocze, rok). Cycle Time – analogia z życia Cycle Time to czas od rozpoczęcia realizacji zamówienia np. obierania ziemniaków czy smażenia kotleta, aż do momentu, gdy kuchnia uzna danie za gotowe i przekaże do wydania. Innymi słowy Cycle Time do czas faktycznego procesu przygotowania posiłku. 4. Flow Efficiency Definicja Flow Efficiency Flow Efficiency (pol. Wydajność albo Sprawność Procesu) to procentowy udział czasu aktywnej pracy nad inicjatywą w całkowitym czasie jej realizacji. Wzór jest prosty: suma czasu aktywnej pracy dzielona przez Lead Time i pomnożona przez 100%. W tej mierze sprawdza się jaką część całego procesu stanowiła realna praca. Odwrotnością tej miary jest procent okresów nieaktywnych: jaki procent całego Lead Time to były przestoje, oczekiwania, blokady decyzyjne czy świadome wstrzymanie działań. W przeciwieństwie do w

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 stworzyć dobrą strukturę takiego wydarzenia. W rozmowie przedstawimy Ci konkretne wskazówki dotyczące przygotowania Retrospektywy. Jeśli jesteś liderem zespołu, kierownikiem projektu, Product Managerem lub Scrum Masterem i masz pod swoimi skrzydłami więcej niż jeden zespół — ten materiał jest dla Ciebie. Porządny Agile · Spotkania usprawnieniowe wielu zespołów Spis treści Jakie mogą być problemy z wielozespołowym spotkaniem usprawnieniowym?7 kroków udanej retrospektywy według Porządny Agile Wskazówki co do sposobu przygotowania skalowanej RetrospektywyFAQ: Spotkania usprawnieniowe wielu zespołówMateriały dodatkowe📄Transkrypcja podcastu „Spotkania usprawnieniowe wielu zespołów” Jakie mogą być problemy z wielozespołowym spotkaniem usprawnieniowym? 1. Marnowanie czasu – Niewłaściwie przeprowadzone wydarzenie może okazać się stratą czasu. Zazwyczaj uczestniczy w nim wiele osób, a jego przebieg trwa dłużej niż standardowa Retrospektywa. Im więcej uczestników, im dłuższe spotkanie, tym większy koszt, a jeśli nie przyniesie konkretnych rezultatów, trudno będzie uzasadnić jego sens. 2. Niewłaściwy skład – Retrospektywa może również mieć niewłaściwy skład. Często pojawia się pokusa, by zaprosić wszystkich członków zaangażowanych zespołów, a nawet dodatkowe osoby pełniące funkcje zarządcze. W efekcie spotkanie staje się zbyt liczne, co utrudnia sprawną pracę i prowadzi do braku decyzyjności lub bezwładności. Taka konfiguracja rzadko sprzyja konkretnym wnioskom i wartościowym rezultatom. 3. Chaotyczny przebieg – Spotkanie przeprowadzone bez odpowiedniego przygotowania może przebiegać w sposób chaotyczny. Obecność wielu osób o różnych temperamentach i z różnych zespołów, które nie miały okazji wcześniej wypracować wspólnych zasad działania, w połączeniu z brakiem struktury, niekontrolowanym dopuszczaniem do głosu i brakiem moderacji – to przepis na nieuporządkowaną dyskusję. Takie spotkanie może być intensywne, ale rzadko przynosi konkretne i mierzalne efekty. 4. Narzekanie – Zdarza się, że spotkanie przeradza się w zbiorową sesję narzekania. Kolejne osoby, przedstawiciele różnych zespołów dzielą się tym, co nie działa i jak mogłoby wyglądać inaczej. Jednak jeśli rozmowa nie jest odpowiednio moderowana, nie prowadzi do żadnych konstruktywnych wniosków. Zamiast tego uczestnicy mogą się wzajemnie nakręcać, co potęguje negatywne emocje i zniechęca do udziału w kolejnych sesjach tego typu. 5. Brak realnych zmian – W efekcie wszystkie wymienione wcześniej błędy mogą prowadzić do braku realnych zmian. Może się okazać, że spotkanie nie kończy się żadnymi sensownymi wnioskami albo  jeśli skalowana Retrospektywa została źle zaplanowana, ustalenia będą powierzchowne. Nawet jeśli pojawią się jakieś propozycje działań, zabraknie konkretnego ustalenia, kto odpowiada za ich wdrożenie. 7 kroków udanej retrospektywy według Porządny Agile  Problemów tego typu może być znacznie więcej, jednak w tym miejscu skupiamy się na kilku najczęstszych, aby zarysować tło przed kolejnymi rozdziałami i podkreślić, dlaczego struktura, dobre przygotowanie oraz konkretne wskazówki, którymi się podzielimy, są naprawdę istotne. Uważamy, że filarem skutecznego wielozespołowego usprawniania się jest porządna struktura. To dobry moment, aby przytoczyć fragment naszego webinaru o Retrospektywie, w którym dzielimy się rekomendacjami dotyczącymi jej przebiegu i struktury. Jeśli jeszcze nie widziałeś tego materiału, znajdziesz go na stronie porzadnyagile.pl/retro. W materiale przedstawiamy również naszą autorską wersję struktury, którą nazywamy siedmioma krokami udanej Retrospektywy według Porządnego Agile’a. Co stanowi pierwszy krok? 1. Zweryfikuj usprawnienia z poprzedniej Retrospektywy Aby Retrospektywa miała sens, warto sprawdzić, czy ustalenia z poprzedniego spotkania zostały zrealizowane. Jeśli nie – należy zastanowić się, dlaczego tak się stało i jakie działania należy podjąć, by zrealizować zaległe usprawnienia. 2. Przypomnij, co będzie przedmiotem i celem Retrospektywy W szczególności wtedy, gdy w spotkaniu biorą udział osoby dołączające okazjonalnie albo gdy zaplanowano konkretny temat do omówienia, warto na początku przypomnieć cel i zakres rozmowy. Ułatwi to uczestnikom zrozumienie, dlaczego biorą udział w spotkaniu i czego można się po nim spodziewać. 3. Zbierz tematy do dyskusji lub przeanalizowania Na tym etapie ważne jest systemowe i przemyślane pozyskanie wkładu od wszystkich uczestników spotkania. Chodzi o to, by każda z zaproszonych osób miała szansę wyrazić swoje obserwacje i spostrzeżenia. Wyrównanie czasu antenowego zapobiega sytuacjom, w których jeden z liderów – świadomie lub nie – nadaje kierunek rozmowie. Dzięki temu zespół może usłyszeć różnorodne perspektywy i zbudować pełniejszy obraz sytuacji. 4. Wybierz z zespołem najważniejsze tematy Zebrane propozycje tematów warto uporządkować i wspólnie zdecydować, które z nich są kluczowe. Aby uniknąć sytuacji, w której zespół spontanicznie skupia się na pierwszym zgłoszonym zagadnieniu, warto oddzielić etap zbierania tematów od ich selekcji, na przykład poprzez głosowanie. Niezależnie od wybranej metody, uczestnicy powinni wiedzieć, że powstanie ranking, który wyznaczy kolejność omawiania tematów zaczynając od tych najistotniejszych. 5. Omów dogłębnie największy problem Piąty krok to dokładna analiza najważniejszego problemu. Gdy zespół wybierze temat do omówienia, warto najpierw zastanowić się, z czego ten problem wynika. Nie zalecamy od razu przechodzić do propozycji rozwiązań, w takim podejściu mogą się pojawić działania powierzchowne lub nieskuteczne. Lepiej zatrzymać się i przyjrzeć się systemowo temu, skąd bierze się dany kłopot i jakie mogą być jego przyczyny. 6. Ustal rozwiązanie omówionego problemu Dopiero po analizie przyczyn i przemyśleniu możliwych scenariuszy działania, zespół podejmuje świadomą decyzję o konkretnym usprawnieniu. To moment, w którym grupa deklaruje, że podejmie się wdrożenia danego rozwiązania i będzie go konsekwentnie realizować. 7. Podsumuj zaplanowane usprawnienia Warto na zakończenie spotkania upewnić się, że wszystkie ustalenia zostały jednakowo zrozumiane przez uczestników. W przypadku dłuższych wydarzeń, jakimi są skalowane Retrospektywy, część tematów poruszanych na początku może już nie być tak świeża w pamięci. Jasne podsumowanie pozwala zebrać najważniejsze wnioski i potwierdzić, co konkretnie zostało ustalone i co należy zrobić po zakończeniu spotkania.Świadomie zatrzymaliśmy się na ogólnym poziomie omówienia tej struktury. Szczegółowe instrukcje, gotowe szablony oraz różne techniki realizacji poszczególnych kroków znajdziesz w naszym webinarze o Porządnej Retrospektywie. Sprawdź materiał na stronie: porzadnyagile.pl/retro. Wskazówki co do sposobu przygotowania skalowanej Retrospektywy Na wstępie warto zaznaczyć, że nieprzypadkowo ten rozdział poświęcamy przygotowaniu skalowanej Retrospektywy. Świadomie podkreślamy, że w porównaniu do standardowego spotkania retrospektywnego jednego zespołu, tutaj znaczenie przygotowania rośnie. Skalowana Retrospektywa to nie jest spotkanie, które można poprowadzić rutynowo z marszu. Skuteczność tego wydarzenia w dużej mierze zależy od przemyślanych kroków przygotowawczych wykonanych przez osobę odpowiedzialną za organizację i moderację. Oczywiście, podczas takiego spotkania zwłaszcza w większym gronie, zawsze mogą pojawić się niespodziewane tematy. Tym bardziej warto zadbać o to, aby wszystkie elementy, które można przewidzieć i zaplanować, były dobrze przygotowane. To one stanowią fundament udanego przebiegu Retrospektywy. 1. Zaproś osoby, które mogą podejmować decyzje  Na skalowanej Retrospektywie powinni pojawić się reprezentanci różnych ról i zespołów, zwłaszcza tacy, którzy mają realny mandat do działania. Choć rozmowa może być wartościowa sama w sobie, to kluczowe jest, aby na koniec spotkania można było podjąć konkretne decyzje. To one stanowią paliwo napędowe dalszych zmian uczestnicy widzą, że coś się dzieje, zapadają decyzje i rzeczywiście ruszamy do przodu. Zadbanie o odpowiedni skład gości leży po stronie organizatora spotkania, to właśnie ta osoba powinna dopasować uczestników do tematyki, którą planujemy poruszyć.To może być misja wewnątrz jakiejś misji, trzeba odpowiednio wytypować uczestników spotkania i upewnić się, że rzeczywiście są to właściwe osoby. W dużej organizacji może się zdarzyć, że nie znamy wszystkich, dlatego tym bardziej warto zadbać o obecność reprezentantów kluczowych obszarów. Przykładowo: osoby odpowiedzialne za proces wdrożeniowy, za współpracę z infrastrukturą, czy przedstawiciele działu prawnego, którzy mogą wziąć odpowiedzialność za wdrożenie zmian.Potrzebujemy na tym spotkaniu ludzi, którzy  nawet jeśli nie podejmą decyzji od razu będą w stanie przyjąć zobowiązania, wprowadzić zmiany samodzielnie lub przekazać je dalej do realizacji. Może to być ich własny zespół, jeśli pełnią funkcje liderskie, albo grupy zadaniowe, jeśli mówimy o ekspertach.Bez odpowiednich osób, nawet najlepsze ustalenia nie mają szans na wdrożenie, dlatego tak ważny jest właściwy skład uczestników usprawnieniowego spotkania wielozespołowego. 2. Przygotuj uczestników przed spotkaniem Druga wskazówka dotyczy przygotowania uczestników przed spotkaniem. Wielozespołowa Retrospektywa nie powinna być organizowana z marszu,szczególnie jeśli biorą w niej udział osoby, które nie mają na co dzień kontaktu z kulturą ciągłego doskonalenia czy z praktyką retrospektyw znanych ze Scruma. W spotkaniu mogą uczestniczyć przedstawiciele różnych poziomów organizacyjnych na przykład dyrektor infrastruktury czy szefowa działu prawnego a więc osoby, które mogą nie znać tej formy pracy lub nie czuć się w niej komfortowo. Również pozostali uczestnicy mogą odczuwać dyskomfort związany z ob

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 odpowiedzialności za produkt i analizę ich wpływu na współpracę zespołów, podejmowanie decyzji i skuteczność wdrażania strategii. Sprawdź, w którym miejscu na osi znajduje się Twój zespół i oceń, czy można w tej kwestii uzyskać usprawnienia. Porządny Agile · Właścicielstwo produktowe – w Biznesie czy w IT? Możliwe modele umiejscowienia właścicielstwa produktowego Pisząc o właścicielstwie produktowym, mamy na myśli miejsce w strukturze organizacyjnej, w którym znajdują się osoby zarządzające produktem, a także ich podległość służbowa. W zależności od firmy, mogą to być Product Ownerzy, Product Managerowie lub specjaliści odpowiedzialni za rozwój funkcjonalności. Niektóre organizacje te stanowiska nazywają inaczej, jednak ich rola pozostaje zbliżona. W niektórych organizacjach stanowiska te mogą mieć inne nazwy, na przykład specjaliści ds. rozwoju funkcjonalności lub podobne role. Nie będziemy tutaj szczegółowo wymieniać wszystkich możliwych wariantów, ale na potrzeby tego tekstu będziemy używać określeń Product Owner i Product Manager, mając na myśli także inne, podobne stanowiska. Spis treści Możliwe modele umiejscowienia właścicielstwa produktowegoBrak jasnego właścicielstwa Zarządca Backlogu w ITZarządzanie produktem po stronie ITPodwójne właścicielstwo Zarządzanie produktem po stronie biznesowej Umocowane zespoły produktoweJak w praktyce podejść do zmiany właścicielstwa produktowego?Zdefiniuj gdzie jesteśUstal jakich rezultatów oczekujesz po zmianieOkreśl argumenty przemawiające za utrzymaniem obecnego stanu rzeczyNarysuj mapę sojuszników i przeciwników zmiany Myśl o strukturze jak o żyjącym bycie, a nie finalnym ustawieniuPrzyjmij, że lepsze jakiekolwiek właścicielstwo niż jego brakFAQ: Właścicielstwo produktowe – w Biznesie czy w IT?📄 Transkrypcja podcastu „Właścicielstwo produktowe – w Biznesie czy w IT?” W różnych organizacjach spotykamy różne modele umiejscowienia właścicielstwa produktowego. Czasami te osoby znajdują się po stronie IT lub technologii, co oznacza, że są częścią zespołu technologicznego i współpracują głównie z działem inżynieryjnym. W innych przypadkach są przypisane do działu biznesowego, gdzie ich rola koncentruje się na strategii i rozwoju produktu z perspektywy rynku. Istnieją też organizacje, w których właściciele produktu funkcjonują jako osobna struktura, często podlegająca bezpośrednio zarządowi. Przeanalizujemy najczęściej spotykane modele i omówimy, jakie konsekwencje niesie za sobą każdy z nich. Nie chodzi o wskazanie, który układ jest najlepszy, ale o przedstawienie, z czym wiąże się każda z tych opcji. Brak jasnego właścicielstwa  Pierwszym punktem na tej osi, od którego warto zacząć, jest sytuacja, w której właścicielstwo produktowe nie jest wyraźnie zdefiniowane. Oznacza to, że trudno wskazać, w jakim konkretnym obszarze organizacji się znajduje – czy jest po stronie IT, czy po stronie biznesu. Jak rozpoznać taki stan rzeczy? Najczęściej przejawia się to w braku spójnej odpowiedzialności za decyzje. Praca nad produktem odbywa się głównie poprzez realizację losowych zleceń, które przychodzą z różnych źródeł. W skrajnym przypadku taka sytuacja prowadzi do równoległego funkcjonowania wielu inicjatyw, projektów i zmian, które nie są ze sobą skoordynowane. Efektem tego jest ich wzajemna konkurencja, a nawet wykluczanie się nazwajem. W rzeczywistości zawsze znajdzie się ktoś, kto podejmie decyzję, w jakim kierunku mają podążać zespoły wytwórcze. Problem pojawia się wtedy, gdy jest to osoba, która podejmuje decyzje z konieczności, a nie z faktycznej odpowiedzialności za produkt. Często rolę tę przejmuje ktoś bez kontekstu biznesowego, kto skupia się wyłącznie na priorytetyzacji zadań w sposób reaktywny, na przykład minimalizując ryzyko niezadowolenia różnych interesariuszy. W praktyce oznacza to, że lider zespołu czy inna osoba pełniąca tę rolę nie kieruje się myśleniem produktowym, lecz stara się jedynie zbalansować różne zlecenia, projekty i zmiany, tak by uniknąć problemów. Podkreślamy to, ponieważ model, w którym nie ma wyraźnego właścicielstwa produktowego, ma głównie wady. Rozumiemy, że niektóre organizacje mogą się w takim stanie znajdować, ale jest to sytuacja, którą warto zmienić.  Zarządca Backlogu w IT Jest to krok w dobrą stronę, ponieważ w organizacji pojawia się osoba, którą można wskazać jako odpowiedzialną za zarządzanie pracami zespołu. Może to być Product Owner, lider zespołu, a czasem nawet Product Manager, choć w tym przypadku nazewnictwo bywa różne. Taka osoba znajduje się po stronie IT, jest częścią konkretnego zespołu, albo funkcjonuje w niewielkiej strukturze w ramach działu technologii. Jej rola polega na zbieraniu inicjatyw i zleceń od interesariuszy biznesowych, organizowaniu projektów oraz przekazywaniu ich do zespołu. Jednak w tym modelu kluczową kwestią jest to, że osoba zarządzająca Backlogiem nie tworzy produktu ani nie ma realnego wpływu na jego kształt. Jej rola sprowadza się do koordynowania przepływu zadań i dbania o ich realizację, ale bez faktycznej sprawczości produktowej. Należy zaznaczyć, że w tym artykule, nawet gdy używamy określeń takich jak Backlog czy Product Owner, nie odnosimy się stricte do Scruma. Te pojęcia na tyle mocno przeniknęły do firm, że stały się naturalnym sposobem opisywania ról i procesów w organizacjach. W przypadku modelu zarządcy Backlogu kluczowe jest to, że taka osoba nie podejmuje decyzji o tym, co zostanie zrealizowane. Jej rola sprowadza się raczej do biernego wykonywania oczekiwań interesariuszy, bez realnego wpływu na kształt produktu.  Warto uczciwie przyznać, że rola zarządcy Backlogu w IT, mimo swoich ograniczeń, ma pewne zalety w porównaniu do modelu, w którym właścicielstwo produktowe w ogóle nie istnieje. Przede wszystkim daje szansę na ucywilizowanie strumienia prac, na uporządkowanie zgłaszanych inicjatyw, minimalną dyskusję z interesariuszami oraz ewentualne grupowanie lub dzielenie inicjatyw w bardziej sensowne części.  Zarządzanie produktem po stronie IT Trzeci model to zarządzanie produktem po stronie IT. W przeciwieństwie do wcześniejszego podejścia, w tym przypadku mamy już wyraźnie określoną rolę, którą można nazwać Product Ownerem. Nie jest to jedynie osoba pasywnie realizująca oczekiwania interesariuszy, lecz ktoś, kto rzeczywiście zarządza produktem. Może posiadać własną wizję, roadmapę, a nawet określone wskaźniki mierzące postęp. Choć taka osoba nadal funkcjonuje w strukturach IT i musi uwzględniać potrzeby różnych interesariuszy, to jednak jej rola wykracza poza mechaniczne realizowanie napływających zadań. W tym modelu pojawia się już myślenie długofalowe, a decyzje dotyczące produktu zaczynają być bardziej świadome i strategiczne. Jest to model, w którym zarządzanie produktem staje się aktywne i opiera się na realizacji konkretnej wizji. Osoba odpowiedzialna za produkt może mieć realny wpływ na kierunek jego rozwoju, a nawet prawo do odrzucania niektórych pomysłów czy oczekiwań poszczególnych interesariuszy. Dzięki temu możliwe jest skupienie się na priorytetach i konsekwentne podążanie za przyjętą strategią, zamiast realizowania przypadkowych zachcianek. Po stronie korzyści znajduje się możliwość konsekwentnej realizacji spójnej wizji. W niektórych produktach ma to kluczowe znaczenie, ponieważ pozwala eliminować przypadkowe inicjatywy i skupić się na istotnych aspektach. Istnieje jednak ryzyko oddalenia się od kontekstu biznesowego, strategii firmy czy współpracy z działami takimi jak sprzedaż, marketing czy wsparcie klienta. Dodatkowym zagrożeniem jest skłonność do preferowania rozwiązań technologicznych. Często pojawiają się zarzuty, że osoby zarządzające produktem od strony IT wybierają priorytety w postaci migracji systemu, aktualizacji technologii czy pełnej refaktoryzacji, zamiast dostarczenia nowych funkcji, które mogłyby przełożyć się na korzyści biznesowe. Jednocześnie są produkty, w których taki model jest optymalny. W szczególności dotyczy to rozwiązań technologicznych, produktów infrastrukturalnych lub firm dostarczających wysoce zaawansowane technologie, gdzie naturalnym miejscem dla zarządzania produktem pozostaje struktura IT. Podwójne właścicielstwo  Model czwarty, umiejscowiony dokładnie na środku omawianej osi, to podwójne właścicielstwo. Niektóre organizacje, często pod wpływem doradców i firm konsultingowych, zdecydowały się na takie rozwiązanie, aby uniknąć dylematu dotyczącego umiejscowienia właścicielstwa produktowego. W tym modelu funkcjonuje dwóch właścicieli produktu – jedna osoba po stronie biznesu i druga po stronie technologii. W założeniu ma to pozwolić na podział odpowiedzialności: osoba z biznesu wnosi perspektywę strategiczną i rynkową, natomiast właściciel techniczny dba o kwestie funkcjonalne, bezpieczeństwo, wydajność oraz długoterminowe koszty utrzymania systemu. Chodzi o to, aby uzupełnić kompetencje i zapewnić, że kluczowe aspekty produktu nie zostaną pominięte. W praktyce oznacza to, że w tym modelu istnieje dwóch Product Ownerów, którzy muszą wspólnie podejmować decyzje dotyczące rozwoju produktu. Ich stanowiska mogą różnie się nazywać, jednak istotą rozwiązania jest konieczność uzgadniania priorytetów i współdecydowania o kierunku działań. To może prowadzić zarówno do lepszego bilansu interesów, jak i do potencjalnych wyzwań związanych z procesem decyzyjnym. Gdybyśmy mieli wskazać największe zagrożenie lub ryzyko tego modelu, to na pewno byłby to dualizm decyzyjny. W skrajnym, negatywnym scenariuszu dwie osoby odpowiedzialne za produkt mogą nie współpracować, wysyłać zespołowi sprzeczne sygnały i ciągnąć produkt w różnych kierunkach. Mocny przedstawiciel biznesu może ignorować potrzeby technologiczne, na przykład zaniedbywać spłatę długu technologicznego lub odkładać aktualizację bibliotek czy frameworków, które wymagają

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 sprawdzone sposoby na wzmacnianie odpowiedzialności zespołów – bez micromanagementu i bez frustracji. To konkretna pigułka wiedzy dla liderów, którzy chcą budować silne, samodzielne i zaangażowane zespoły. Porządny Agile · Jak szef produktu buduje odpowiedzialność zespołów? Spis treści Wyznaczaj ambitne celeNieustannie przypominaj strategię firmy i produktuWłączaj zespoły w kreowanie rozwiązańWyjaśniaj kontekst biznesowy swoich decyzjiPozwalaj eksperymentować i popełniać błędyOczekuj efektów, a nie dowożenia zakresówZapewnij zespołom dostęp do feedbacku od klientów Znajdź czas na pracę 1 na 1 ze swoimi ludźmiStwórz ścieżki rozwoju dla członków zespołuZaplanuj proces wzmacniania odpowiedzialnościFAQ: Jak szef produktu buduje odpowiedzialność zespołów?📄Transkrypcja podcastu „Jak szef produktu buduje odpowiedzialność zespołów?” Porady dla szefa produktu pomagające budować odpowiedzialność zespołów W ramach naszego podcastu, nagraliśmy odcinek o budowaniu odpowiedzialności za produkt, skierowany głównie do Product Ownerów i Scrum Masterów. Możesz go znaleźć na stronie www.porzadnyagile.pl/31, pod tytułem: „Wzmacnianie odpowiedzialności zespołu za produkt”. Dziś podejmujemy podobną tematykę, ale w zupełnie innych okolicznościach i z myślą o osobach zarządzających większymi strukturami – kilkoma zespołami, produktami lub całą strukturą produktową. Mamy dla Ciebie dziesięć porad dotyczących tego, co osoba zarządzająca strukturą produktową może zrobić, aby budować odpowiedzialność zespołów wytwórczych za produkt, nad którym pracują. Wyznaczaj ambitne cele Wszystko zaczyna się od konkretnego, ambitnego i mierzalnego celu. Warto przy tym wykazać się wizjonerskim podejściem, pokazując zespołom perspektywę wykraczającą poza to, co obecnie są w stanie dostrzec. Takie podejście wiąże się z wyższymi oczekiwaniami, które motywują do poszukiwania mniej oczywistych rozwiązań. Aby osiągnąć ambitny cel, zespół powinien poświęcić czas na przemyślenie sposobów realizacji i wzięcie odpowiedzialności za efekt końcowy. Ograniczenia – na przykład czasowe – mogą skłonić do kreatywnego podejścia: radykalnych uproszczeń, sięgnięcia po nowe technologie lub zastosowania nieszablonowych rozwiązań, które w danej organizacji będą zaskakujące i świeże. Jeśli żaden z przypadków wymienionych wcześniej nie dotyczy Twojej sytuacji, ta porada jest tym bardziej dla Ciebie. W roli szefa produktu warto czasem samodzielnie stworzyć lub zasymulować warunki, w których pojawi się ambitny cel. Chodzi o świadome sprowokowanie sytuacji, która postawi zespoły przed wyzwaniem.Mamy na myśli odwrócenie niekorzystnej sytuacji, gdy zespoły są lekko rozleniwione, nie mają wyzwań, a cele, które przed nimi stoją, są miałkie, lekkie i letnie. Brak ambitnych celów może przyczyniać się do rozluźnienia i podejścia w stylu: „zrobię swoje, jakoś to się wszystko później złoży, będzie dobrze”. Mamy jednak bardzo pozytywne doświadczenia z różnych organizacji, w których pojawienie się wyzwania – rozumianego jako ambitna aspiracja, a nie problem – działało motywująco. To właśnie taki cel sprawia, że zespół musi się zmobilizować, zebrać, przestać lekceważyć pewne sprawy, wysilić się i poszukać kreatywności. W efekcie zaczyna brać sprawy w swoje ręce i stara się osiągnąć coś, co na pierwszy rzut oka może wydawać się zbyt duże, zbyt trudne lub nierealne do wykonania w danym czasie. Nieustannie przypominaj strategię firmy i produktu Zakładamy, że zarówno strategia firmy, jak i produktu istnieje – w większości organizacji faktycznie tak jest. Jednak równie często zdarza się, że choć strategia jest dobrze znana na wyższych poziomach zarządzania i stanowi ich codzienność, to niekoniecznie dociera do zespołów operacyjnych ani liderów pierwszej linii. Właśnie dlatego rolą szefa produktu jest regularne, konsekwentne – a z perspektywy niektórych może nawet nadmierne – przypominanie, na czym polega strategia i dlaczego została przyjęta w takiej formie. Warto też zaznaczać, czego w strategii nie ma oraz wyjaśniać, jak poszczególne tematy się ze sobą łączą i w jaki sposób podejmowane decyzje wpisują się w szerszy kontekst. O samych decyzjach powiemy więcej w kolejnych punktach. Nieustanne przypominanie o strategii to w praktyce łączenie kropek między tym, co organizacja chce osiągnąć na poziomie strategicznym, a tym, co faktycznie dzieje się w zespołach. Z perspektywy codziennej pracy członkowie zespołu często koncentrują się na pojedynczych zadaniach, a w najlepszym wypadku – na realizowanych projektach, inicjatywach czy zmianach w produkcie. Brak jasnego powiązania między tymi działaniami a szerszym kontekstem strategicznym może prowadzić do niezrozumienia podejmowanych decyzji czy opracowania rozwiązań, które nie są tak trafne, jak mogłyby być. Zrozumienie, dlaczego pewne działania są priorytetowe, a inne zostały odłożone na później lub całkowicie pominięte, pozwala zespołom lepiej dopasować swoje działania do kierunku, w jakim zmierza firma. Znajomość strategii firmy i produktu nie tylko ułatwia podejmowanie trafnych decyzji, lecz także wzmacnia poczucie odpowiedzialności w zespole – bo kiedy rozumiemy sens działań, łatwiej nam się z nimi utożsamić i brać za nie odpowiedzialność. Włączaj zespoły w kreowanie rozwiązań Głównym przesłaniem tej porady jest zachęta, aby nie traktować zespołów jak podwykonawców – czyli grupy, której zleca się precyzyjne zadania i oczekuje jedynie ich wykonania. Warto zamiast tego podejść do zespołu jak do partnera, który posiada samodzielność i świadomość celu. Zespół, rozumiejąc strategię firmy oraz produktu, powinien mieć przestrzeń do kreowania rozwiązań – takich, które najlepiej odpowiadają na potrzeby organizacji, uwzględniając dostępny czas, możliwości, a także ograniczenia technologiczne. Dobrze zbudowany zespół wytwórczy potrafi podejmować trafne decyzje operacyjne, często lepiej niż osoby spoza jego struktury. Wynika to z faktu, że wiele decyzji dotyczy szczegółów, które mogą umknąć radaru osobom zarządzającym wyższymi szczeblami. Właśnie dlatego tak ważne jest umożliwienie zespołowi wpływu na to, jak realizowane są zadania. Oznacza to, że zespoły mogą być włączone w proces budowania roadmapy oraz aktywnie konsultowane podczas definiowania celów, większych inicjatyw czy kolejnych kroków rozwojowych, które mają zrealizować. W rozmowach na ten temat z osobami zarządzającymi często pojawia się jednak obawa o podejście zero-jedynkowe – słyszę wtedy: „Nie będę ich włączać, bo źle to wymyślą.” Warto więc podkreślić, że ta porada brzmi: włączaj zespoły, a nie przerzuć na zespoły całą odpowiedzialność. W większości organizacji pełne oddelegowanie tematu rozwiązań na zespoły nie jest w pełni realne. Jeśli w Twojej firmie jest inaczej – to świetnie. W praktyce jednak wiele organizacji znajduje się w innym miejscu. Dlatego mówimy o współtworzeniu – o takim podejściu, w którym zarówno wyższa kadra zarządzająca, jak i zespoły oraz liderzy produktów angażują się we wspólne wypracowanie rozwiązań. Chodzi o unikanie sytuacji, w której zespołom zleca się z góry narzucone, zamknięte rozwiązanie – bez możliwości wpływu na jego kształt. Wyjaśniaj kontekst biznesowy swoich decyzji Ten temat pojawił się już przy omawianiu strategii, ale warto do niego wrócić. W trakcie rozwoju produktu pojawia się wiele decyzji biznesowych – niektóre mogą być dla zespołu niezrozumiałe, inne sprzeczne z wcześniejszymi ustaleniami. Czasami są to decyzje niepopularne, a nawet trudne do przyjęcia. Przykłady? Zamknięcie produktu, rezygnacja z obsługi konkretnego segmentu rynku lub przekazanie części biznesu innemu produktowi w ramach organizacji. Tego typu zmiany potrafią silnie zdemotywować zespół, a w skrajnych przypadkach prowadzić do biernego oporu, jawnego lub ukrytego sabotowania działań czy błędnych interpretacji podejmowanych kroków. Dlatego tak ważne jest wyjaśnianie zespołom kontekstu podejmowanych decyzji. Pokaż szerszą perspektywę – to, co dla Ciebie jest oczywiste, wcale nie musi być zrozumiałe dla innych. Brak wiedzy o przyczynach danej decyzji może zadziałać demotywująco, a z kolei dobre wyjaśnienie potrafi zbudować zrozumienie i zaangażowanie. To działa także w drugą stronę – jeśli podejmujesz pozytywną decyzję, która otwiera nowe możliwości, pokaż zespołowi, skąd się wzięła. Pozwól im poczuć satysfakcję i entuzjazm, który towarzyszy ci w danym momencie. Patrząc na tę poradę w dłuższej perspektywie, regularne wyjaśnianie kontekstu biznesowego sprawia, że zespoły z czasem znacznie lepiej rozumieją środowisko, w którym funkcjonują. Wiedzą, dlaczego z pewnych działań się rezygnuje, a inne należy realizować w określony sposób.Nic nie demotywuje tak bardzo jak komunikat: „Od teraz robimy tak” – bez podania przyczyn czy szerszego uzasadnienia. W praktyce często prowadzi to do frustracji. Zespoły, które wielokrotnie spotykają się z takim podejściem, zaczynają reagować z sarkazmem i dystansem. W skrajnych przypadkach pojawia się przekonanie: „Cokolwiek powiemy, i tak zrobią po swojemu”. To z kolei prowadzi do postawy: „Wykonujemy swoje zadania, ale efekt końcowy nas nie interesuje”. Taki zespół potrzebuje zrozumieć powody decyzji. To pozwala mu utożsamiać się z celem, podejmować lepsze decyzje na co dzień i realnie dbać o rezultat końcowy. Pozwalaj eksperymentować i popełniać błędy W tej poradzie pojawiają się dwa istotne elementy: eksperymentowanie i popełnianie błędów. Eksperymentowanie zazwyczaj przychodzi z łatwością, ale akceptacja ewentualnych pomyłek już niekoniecznie. W organizacjach, w których odpowiedzialność produktowa jest niska, zespoły często unikają podejmowania decyzji. Gdy dopytujemy, z czego to wynika, okazuje się, że w tle pojawiają się wspomnienia sytuacji, w których popełnione błędy spotkały się z nieprzychylną reakcją. Może to dotyczyć nietrafionych

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 i narzędzia, aby osiągać najlepsze efekty. Poznaj sześć inspiracji spoza agile, takich jak zarządzanie projektami, Lean, czy automatyzacja, które mogą odmienić sposób pracy Twojego zespołu. Porządny Agile · Jedna najlepsza metoda pracy nie istnieje Tytuł może brzmieć zaczepnie, ale dobrze oddaje istotę tego, o czym chcemy dzisiaj napisać. Ten materiał będzie o tym, jak czerpać z różnych podejść, łączyć je i dopasowywać do kontekstu, aby osiągać sensowne efekty. Wymieniamy poniżej sześć konkretnych inspiracji, które naszym zdaniem warto rozważyć, a które wykraczają poza klasyczne metody zwinne. Spis treści Zarządzanie ProjektamiZarządzanie finansamiPrzywództwoKoncepcja zarządzania LeanInżynieria oprogramowania Zarządzanie zmianąKontrowersje przy stosowaniu różnych koncepcji zarządzaniaThe Oath of Non-AllegianceFAQ: Jedna najlepsza metoda pracy nie istniejeMateriały dodatkowe📄Transkrypcja podcastu „Jedna najlepsza metoda pracy nie istnieje” Zarządzanie Projektami W zależności od twojego doświadczenia, firmy, w której pracujesz, oraz roli, jaką pełnisz, może cię to albo zaskakiwać, albo wydawać się oczywiste. Zarządzanie projektami często bywa przedstawiane jako przeciwieństwo podejścia zwinnego. Z tego powodu niektórzy na starcie odrzucają wszystko, co wiąże się z tym szerokim obszarem skutecznego zarządzania inicjatywami. Mamy doświadczenie zarówno w koordynowaniu projektów, jak i w ich zarządzaniu. Sięganie po narzędzia i techniki projektowe jest dla nas czymś naturalnym. Jednak obserwując rynek, widzimy, że wcale nie jest to tak powszechne podejście. Dlatego nieprzypadkowo umieszczamy zarządzanie projektami na pierwszym miejscu tej listy. Dlaczego zarządzanie projektami przyda się w zwinnej organizacji, zwinnym zespole czy produkcie? Wiele inicjatyw, które są realizowane przez takie zespoły, w praktyce faktycznie jest projektami . Zwłaszcza jeśli spojrzymy na to od strony czystej teorii. Konkretne praktyki, sposoby myślenia i organizowania przedsięwzięć wynikające z solidnych podstaw zarządzania projektami mogą okazać się wręcz niezbędne. Odrzucanie koncepcji zarządzania projektami może oznaczać niepotrzebne zamykanie się na zestaw narzędzi, które mogłyby być wartościowe. Dlatego warto sięgnąć po inspiracje płynące z tego obszaru. Wykres Gantta Jako konkretne narzędzie z zarządzania projektami wybraliśmy wykres Gantta. Bywa odrzucany na zasadzie „to jest ten stary, zły project management, a my przecież teraz pracujemy zwinnie”. Uważamy, że sama metoda może być bardzo pomocna w każdym zespole.  Jak zastosować wykres Gantta w praktyce zwinnego zespołu? Jacek wykorzystywał planowanie inspirowane wykresem Gantta do organizowania pracy na Sprint. Jego zespół starał się dobrze rozrysować kolejność działań, określić, kto będzie się czym zajmował, oszacować czas pracy. Mając przed oczami taki plan mógł zidentyfikować zależności i elementy krytyczne. Dzięki temu zespół wiedział, co musi zostać ukończone wcześniej, aby umożliwić kolejne kroki. Takie podejście bardzo dobrze działało – osiągali Cele Sprintu, mieli dobrą przewidywalność i lepszą kontrolę nad postępem. Wykres Gantta jako narzędzie jest adekwatny, ale kluczowe jest to, jak go umiejętnie połączyć ze zwinnością. Jedną z praktyk może być zespołowe planowanie pracy. Zauważ, że w powyższej historii o zespole Jacka cały zespół uczestniczył w tym procesie. Razem budowali plan, razem wyceniali, razem układali harmonogram. Wszyscy rozumieli, na czym polega struktura pracy, bo wykres Gantta jest narzędziem intuicyjnym. Oprócz zastosowania do planowania Sprintu, Wykres Gantta w zwinnych zespołach można też wykorzystać między innymi do: planowania wdrożenia,  planowania skomplikowanej migracji, koordynacji pracy wielu zespołów.  Zarządzanie finansami Często zwinne zespoły, zwłaszcza te zbyt mocno zapatrzone w konkretne frameworki, dystansują się od twardego świata finansów. Rozliczenia, budżetowanie, planowanie cash flow – te pojęcia bywają traktowane jako coś obcego, nienależącego do ich rzeczywistości. Dla wielu osób mogą to być terminy niezrozumiałe albo kojarzone z klasycznym, starym stylem zarządzania. Światem osobnych działów i specjalistów, którzy wymagają uzupełnionego szablonu i operują założeniami obcymi w zwinnym świecie. Widzimy niepokojący trend postrzegania agile’a jako narzędzia do poprawy komfortu zespołu, zamiast sposobu na osiąganie rezultatów biznesowych, również finansowych. Naszym zdaniem odseparowanie świata finansów od świata zwinności jest błędem. Jeśli organizacja rozwija produkty, usługi, czy też realizuje duże inicjatywy, to świadomość finansowa zespołu jest kluczowa. Na pewnym poziomie organizacyjnym dochodzi zawsze do zainteresowania kosztami, budżetowaniem i sposobem rozliczania pracy. Jeśli każda rozmowa o finansach będzie wywoływać dystans, to bardzo łatwo zbudować wizerunek zespołu, który nie rozumie realiów biznesowych. A przecież zespół nie działa w próżni – każda inicjatywa kosztuje, a firma inwestuje po to, żeby zarobić. Koszt Sprintu Konkretna praktyka, którą proponujemy, to monitorowanie i kontroling kosztów per Sprint. Sprowadza się to do dosyć prostego pytania: ile kosztuje firmę jeden Sprint danego zespołu? Nie chodzi o to, by porównywać zespoły między sobą, bo już sam różny skład osobowy sprawia, że koszty będą inne. Chodzi raczej o uświadomienie tego zespołowi i osobom zarządzającym procesem. Daje to szansę na podejmowanie lepszych decyzji menedżerskich dotyczących kosztów pracy i wartości, jaką dany zespół generuje. To podejście składa się z dwóch kluczowych elementów:  jakie są faktyczne czynniki kosztów – nie tylko koszty osobowe, ale także wszelkie dodatkowe wydatki; jak te koszty są liczone, jakie są ich typy i jak wpływają na organizację. Dla zespołu może to być nowa perspektywa, ale dla zarządzania całą firmą ma to ogromne znaczenie. Jest to ważne zarówno w kontekście efektywności pracy, jak i strategicznego podejmowania decyzji. Pamiętamy bardzo żywą reakcję zespołu, kiedy dowiedzieli się, że koszt jednego Sprintu wynosi kilkadziesiąt tysięcy złotych. Padł wtedy komentarz: „A my w tym Sprincie dowozimy tylko jakiś prosty checkbox na interfejsie użytkownika”. To był moment przełomowy – pojawiło się u nich poczucie, że każda zmiana, nawet najmniejsza, ma swój realny koszt. Ta świadomość skłoniła zespół do głębszej refleksji: czy na pewno wszystkie zaplanowane rzeczy są konieczne? Czy na pewno muszą być realizowane w tak szerokim zakresie? Zaczęli postrzegać swoją pracę nie tylko jako wykonywanie kolejnych zadań, ale jako inwestycję. Ostatecznie, żeby organizacja mogła działać, zapewniać wynagrodzenia, benefity i – w bardziej humorystycznym tonie – owocowe czwartki, firma musi generować przychody.  Przywództwo Jest wiele teorii zarządzania, które podkreślają, że w zależności od sytuacji i kontekstu należy stosować różne podejścia. Niewłaściwe zrozumienie koncepcji samorganizacji i samozarządzania może osłabić pozycję lidera. Może to prowadzić do sytuacji, w których oczekiwane i potrzebne są zdecydowane reakcje, a w rzeczywistości ich nie ma. Zwinne metody często zakładają, że ma się do czynienia z doświadczonym, zaangażowanym i zmotywowanym zespołem. Taki zespół sprawnie podejmuje decyzje, a jeśli pojawi się konieczność korekty – szybko ją wdraża. To są wartościowe postawy w wielu sytuacjach, jednak nie zawsze będą najlepszym wyborem. Co o roli przywództwa wspominają konkretne modele zarządzania? Situational Leadership – koncepcja znana z modeli Blancharda jasno mówi, że duża swoboda, przekazywanie odpowiedzialności i wyznaczanie celów bez ścisłej kontroli sprawdzają się u jednostek (i w efekcie – w zespołach) o wysokim poziomie dojrzałości i doświadczenia. Jeśli zespół jako całość jest początkujący, jeśli jego członkowie dopiero uczą się pracy w danym kontekście, to pełna autonomia może prowadzić do impasu lub błędnych decyzji. W takich przypadkach bardziej efektywne może być podejście, w którym lider zapewnia większe wsparcie i kierunek. Cynefin – koncepcja Snowdena podkreśla, że w sytuacjach złożonych zespoły mogą skutecznie eksperymentować i podejmować decyzje w sposób iteracyjny. Natomiast w sytuacjach chaotycznych, gdy konieczna jest natychmiastowa reakcja, potrzebne jest szybkie podejmowanie decyzji i wyznaczenie jasnego kierunku działania. W takich momentach nadmierne czekanie na samoorganizację zespołu może pogłębić problem. Obie koncepcje wskazują na to, że domyślne podejście zwinne, oparte na zespołowej współodpowiedzialności, nie zawsze jest najlepszym rozwiązaniem. Dobór odpowiedniego stylu zarządzania powinien zależeć od kontekstu i poziomu dojrzałości zespołu. Zachęcamy, by nie wykluczać wyraźnego i mocnego przywództwa w przypadkach, które tego wymagają. Koncepcja zarządzania Lean Kolejną inspiracją, którą uważamy za wartą rozważenia, jest koncepcja zarządzania Lean. Lean Management, znany z fabryk i optymalizacji procesów w firmach, składa się z wielu konkretnych praktyk oraz całej filozofii. W pewnym stopniu oddaje ją polskie tłumaczenie (choć niezbyt przez nas lubiane) – szczupłe zarządzanie. Jest to podejście ukierunkowane na szukanie okazji do optymalizacji procesów, obniżania kosztów oraz maksymalizowania wartości dodanej. Wartości zarówno z perspektywy klienta końcowego, jak i klienta procesu czy wartości uzyskanej z danej inicjatywy. Jak Lean łączy się ze Scrumem? Kilkanaście lat temu mieliśmy okazję uczestniczyć w szkoleniu prowadzonym przez Jeffa Sutherlanda, jednego ze współtwórców Scruma. W nazwie szkolenia oczywiście pojawiało się odniesienie do Scruma, ale zaskoczyło nas, to jak wiele miejsca prowadzący poświęcił Leanowi. Całe duże bloki i ćwiczenia dotyczyły m.in. identyfikowania marnotrawstwa, sposobów mierzenia procesów i eliminowania zbędnych działań. Było to dla

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, takie jak różnice w rozumieniu „skończonego produktu” czy podział na my i wy? Podpowiemy Ci jak stworzyć środowisko, w którym biznes i technologia działają jak jeden zespół. Znajdziesz tu konkretne, praktyczne wskazówki, które możesz zastosować od razu w swojej organizacji. Porządny Agile · Jak – Zblizyc – Do – Siebie – Biznes – I-it Inspiracją do tego  artykułu jest kilka niezależnych głosów. Na początek opowiemy ci krótką historię – oczywiście zanonimizowaną, aby nie zdradzać szczegółów dotyczących zespołu, z którym pracujemy. Potem podzielimy się konkretną pulą porad jak usprawnić sytuację.  Spis treści Przykłady podziałów między częściami organizacjiJak zbliżyć do siebie Biznes i IT w praktyce?FAQ: Jak zbliżyć do siebie biznes i IT?Materiały dodatkowe📄Transkrypcja podcastu „Jak zbliżyć do siebie biznes i IT” Przykłady podziałów między częściami organizacji Podczas jednego ze strategicznych spotkań strona technologiczna i biznesowa omawiały plan pracy na najbliższy rok. Przełom roku dla wielu organizacji to czas  budżetów, planów i określania rocznych celów. Zwróciliśmy uwagę na pewien kluczowy problem. Sytuacja dotyczyła planowania rozwoju produktu, ale szybko okazało się, że istnieje różnica w rozumieniu, co oznacza „skończony produkt”. Zespół technologiczny przedstawił rozwiązanie jako gotowe – aplikacja działała i była funkcjonalna. Natomiast strona biznesowa zauważyła, że produkt nie jest jeszcze gotowy w sensie biznesowym. Brakowało procedur wdrożeniowych, przygotowania dla klientów i całej otoczki biznesowej, która umożliwia skuteczne wprowadzenie produktu na rynek. Współpraca między technologią a biznesem w tej organizacji już funkcjonowała całkiem dobrze. Miała swoje sukcesy, ale nadal istniał potencjał do lepszego zgrania tych dwóch obszarów. Właśnie dlatego chcemy w tym artykule podzielić się praktykami, które mogą pomóc w takich sytuacjach. Nie tylko będziemy je omawiać, ale również planujemy wdrożyć je w tej konkretnej organizacji i zobaczyć, jak się sprawdzą. Powyższy przykład zawiera bardzo popularny i często spotykany wzorzec – wyraźna linia podziału między biznesem a IT. Jednak takich sytuacji w dużych organizacjach jest znacznie więcej. Na przykład, współpraca pomiędzy działem marketingu a sprzedaży bywa wyzwaniem. Innym przykładem może być różna optyka i podejście osób pracujących w biurach w firmach produkcyjnych w porównaniu do tych, które pracują na liniach produkcyjnych. Podobne różnice widać między ludźmi pracującymi w „centrali” a tymi, którzy działają „w terenie”. Tych przykładów można by wymieniać wiele. Ostatecznie, z perspektywy zarządzania organizacją, zależy nam na tym, aby te różne grupy – często funkcjonujące jakby w swoich „silosach” – potrafiły efektywnie współpracować. Właśnie o tym przeczytasz poniżej.  Chcemy się skupić na przykładach związanych stricte z interakcją między biznesem a technologią. Chociaż mamy poczucie, że nasze porady mogą być z powodzeniem stosowane także w szerszym kontekście. Dlatego, jeśli posłużymy się bardzo konkretnym przykładem, nie traktuj tego jako naszej wytycznej, że tylko w takich sytuacjach można z nich skorzystać. Jak zbliżyć do siebie Biznes i IT w praktyce? Przedstawimy Ci 10 konkretnych wskazówek – propozycji, które wybraliśmy na podstawie własnych doświadczeń. Są to rzeczy, które najczęściej stosujemy w praktyce albo obserwujemy w firmach, z którymi współpracujemy. Jeśli już stosujesz którąś z tych metod, to świetnie – może warto ją jeszcze bardziej pogłębić. Jeśli czegoś z naszej listy jeszcze nie wdrożono w twoim środowisku, zachęcamy do wzięcia tego pod rozwagę. Propaguj wizję docelowego stanu współdziałania To kluczowy punkt, szczególnie jeśli działasz w organizacji, w której głębokie, rzeczywiste współdziałanie ponad podziałami nigdy wcześniej nie funkcjonowało. Pokazanie, że można pracować inaczej, wymaga narysowania wizji przyszłości, która inspiruje i motywuje. Możesz to zrobić, opowiadając historię, jak mogłoby to wyglądać. Bazuj na swoich wcześniejszych doświadczeniach lub inspiracjach zdobytych na konferencjach, podcastach, webinarach czy poprzez inne źródła dostępne w internecie. Takie bodźce mogą stać się impulsem do rozpoczęcia rozmów na temat tego, jak wygląda „lepszy świat” – świat, w którym bliska współpraca między biznesem a IT jest możliwa. Taka wizja nie tylko zachęca, ale również otwiera przestrzeń do refleksji, że można działać efektywniej, lepiej i bardziej spójnie jako organizacja. Zachęcamy do dzielenia się tą wizją, pokazania swojego wymarzonego stanu. Mówieniu o swoim marzeniu na temat tego, jak współdziałanie mogłoby wyglądać. To współdziałanie wiąże się z bardzo konkretnymi szczegółowymi praktykami. Ale przestrzegamy przed podejściem: „Wprowadźmy jedną czy drugą praktykę i liczmy na to, że będzie lepiej”. Zachęcamy, aby zacząć właśnie od wizji. Nie bój się propagować swoich pomysłów. To, co zbliża biznes i IT, jest czymś o wiele szerszym i często nienamacalnym. Wykracza daleko poza poszczególne praktyki, nawet te, które sami wymienimy. Wizja to coś, co trzeba nieustannie wspierać, pokazywać i komunikować. Tak jak wspomnieliśmy wcześniej, może się okazać, że w twojej organizacji takie podejście nie jest normą. Może być czymś zupełnie innym od dotychczasowych praktyk, co sprawia, że ludzie mogą nie być w stanie sobie tego wyobrazić. Ustal wspólne cele Jednym z powodów rozdźwięku, podziału czy myślenia w kategoriach My-Wy, jest to, że różnym osobom, które potencjalnie powinny współpracować, przypisuje się różne cele. Dlatego sugerujemy, aby cała grupa profesjonalistów i ekspertów, zaangażowanych w rozwój szeroko rozumianego produktu, miała wspólne cele. Klasycznym przykładem jest sytuacja, w której biznes ma bardzo konkretne cele do osiągnięcia, a zespoły IT koncentrują się na przykład na spłacaniu długu technologicznego. Taki układ naturalnie prowadzi do tarć i poczucia grania do różnych bramek – biznes chce jedno, IT dąży do czegoś innego. Rozwiązaniem jest znalezienie sposobu na pogodzenie tych interesów. Możliwe jest równoczesne realizowanie celów biznesowych i dbanie o kwestie technologiczne. Warunkiem jest to, by zarówno osoby ze strony biznesu, jak i IT miały jasność, co jest ich najważniejszym priorytetem i wspólnym miernikiem sukcesu. Jednocześnie należy wygospodarować czas na działania związane ze spłatą długu technologicznego, zamiast odkładać to na bliżej nieokreślone „później”. Kluczowe w tej układance jest zapewnienie absolutnej jasności, jakie są wspólne cele. Potrzebne jest też regularne monitorowanie ich realizacji, tak aby obie strony miały pełną świadomość postępów. Zapewnij integrację zespołu Może to wydawać się oczywiste, że w zespole warto zadbać o integrację. Jednak w szczególności w realiach pracy zdalnej czy hybrydowej coraz częściej obserwujemy erozję zespołowości. Przykładem może być świeża historia, którą Jacek usłyszał od znajomego. Opowiadał o sytuacji w swojej organizacji, gdzie ludzie spotykają się osobiście dosłownie raz w roku – przy okazji wspólnej wigilii. W trakcie roku pracy nie ma praktycznie żadnych okazji, aby się poznać, porozmawiać o czymś innym niż obowiązki zawodowe. Nie ma też możliwości spędzić razem czas w mniej formalnych warunkach. Tymczasem, czy tego chcemy, czy nie, jesteśmy istotami społecznymi. Pracuje się o wiele łatwiej i efektywniej, gdy znamy osoby po drugiej stronie, ufamy im i rozumiemy, kim są.  Zachęcamy do świadomego budowania takiej postawy, że gdy się dobrze znamy, jesteśmy dogadani i zżyci, wiele spraw staje się prostszych. Zwłaszcza w realiach pracy hybrydowej czy zdalnej, gdzie naturalne okazje do integracji, takie jak wspólny lunch, kawa, czy po prostu przebywanie blisko siebie w biurze, coraz bardziej zanikają. Dlatego warto podjąć świadomy wysiłek i wdrożyć konkretne działania, które pozwolą dobrze rozumianemu zespołowi lepiej się zintegrować. Może to oznaczać zaproszenie wszystkich do wspólnego miejsca, spędzenie czasu na zrozumieniu tego, co jest do zrobienia. Przy okazji będzie to lepsze poznanie się na poziomie międzyludzkim. Proponujemy również zbudowanie kontraktu na współpracę, który jasno określi zasady działania zespołu. Tego rodzaju inicjatywy pomagają wzmocnić relacje i tworzyć solidne podstawy do dalszej pracy. Dodatkowo warto zadbać o coś, co na pierwszy rzut oka może nie być oczywiste – stworzenie wspólnego słownika. Zdefiniowanie kluczowych pojęć w zespole jest szczególnie ważne, bo w wielu organizacjach podstawowe terminy, takie jak „kredyt” czy „transakcja”, mogą oznaczać zupełnie różne rzeczy w zależności od działu czy perspektywy. Brak wspólnego języka może prowadzić do nieporozumień, które z kolei utrudniają współpracę. Dlatego inwestowanie w budowanie zrozumienia, zarówno na poziomie relacji międzyludzkich, jak i języka, którym się posługujemy, jest kluczowe dla skutecznej integracji i efektywnej współpracy. Zwiększaj odpowiedzialność zespołu Tutaj bardzo świadomie mówimy „zwiększaj odpowiedzialność”, ponieważ zakładamy, że jakaś odpowiedzialność w zespole już jest przekazana. Jednak jednym z nieoczywistych zjawisk, które obserwujemy, jest to, że liderzy organizacji często denerwują się na pasywne postawy w zespołach lub na podejście silosowe. Gdyby jednak bliżej się temu przyjrzeć i zadać sobie pytanie, z czego to wynika, okazuje się, że jedną z przyczyn może być brak rzeczywistego przekazania odpowiedzialności do zespołu. Często nie ma też odpowiedzialności przypisanej poszczególnym osobom reprezentującym różne specjalizacje w zespole. Efektem takiej sytuacji jest to, że większe decyzje i działania są przesuwane w górę, zgodnie z linią raportowania. W efekcie nie tylko brakuje dobrej współpracy w obrębie zespołu, ale również proces decyzyjny staje się wydłużony. Często decyzje są po prostu oznajmian

Czasem zdarza się, że w organizacji pojawi się projekt, który wymaga działań wielu zespołów zwinnych. Przygotowaliśmy zestawienie pewnych praktyk, z których możesz ułożyć sobie własne rozwiązanie, skrojone do odwagi, dojrzałości i możliwości firmy. Zwróciliśmy też uwagę na ważne przestrogi, które możesz spotkać podczas inicjatyw wielozespołowych. Porządny Agile · Inicjatywy wielozespołowe Spis treści Założenia do sytuacji, o której powiemyProponowane praktyki pracy wielu zespołów nad jedną inicjatywąPrzestrogi oraz przemyślenia przy pracy wielozespołowejFAQ: Inicjatywy wielozespołowe📄Transkrypcja podcastu „Inicjatywy wielozespołowe” Założenia do sytuacji, o której powiemy Zakładamy, że w organizacji działają już pewne zespoły zwinne, stanowiące bazę. Funkcjonują one na zadowalającym poziomie, bez wyraźnych patologii oraz z zaufaniem w zakresie realizacji własnych zadań w dobrze znanych im obszarach. Rozpatrywać będziemy przypadek pojawienia się nowego, rozbudowanego i istotnego tematu, którego wdrożenie wymaga współpracy wielu zespołów jednocześnie. Co mamy na myśli, gdy mówimy wspólny temat dla wielu zespołów? Przyjrzyjmy się kilku przykładom, które mogą odnosić się do twojej sytuacji.  Przebudowa lub przepisanie systemu: starsze, rozbudowane systemy często wymagają gruntownej modernizacji lub całkowitego przepisania, aby wspierać konkretny kawałek procesu biznesowego. Proces ten może obejmować prace niemalże wszystkich zespołów technologicznych w organizacji. W wielu organizacjach starsze rozwiązania bywają na tyle rozległe i kluczowe dla całości, że stworzenie nowej wersji wymaga zaangażowania niemal wszystkich zespołów technologicznych, a czasem nawet wszystkich. Radykalne zmiany biznesowe: Innym przykładem jest radykalna zmiana biznesowa, na przykład spowodowana nowymi regulacjami prawnymi, przeobrażeniem wizerunku lub marki czy przejęciem innej firmy. W takiej sytuacji kluczowe elementy, takie jak wizualne czy marketingowe atrybuty, rozproszone są po całej organizacji, we wszystkich systemach i procesach. To z kolei wymusza skoordynowane działania bardzo wielu zespołów, a niekiedy również wszystkich bez wyjątku. Nowa linia biznesowa: wprowadzenie nowej linii biznesowej, wymaga zbudowania komponentów w różnych miejscach w organizacji, technologiach, warstwach i lokalizacjach organizacyjnych. Przykładem może być nowa hurtownia danych, przebudowa kluczowego systemu bazowego, modyfikacje w aplikacji mobilnej czy integracje upsellingowe z już istniejącymi produktami. W takich przypadkach sukces biznesowy zależy od w miarę jednoczesnej realizacji zmian w wielu miejscach organizacji. Nie jesteśmy zwolennikami nadmiernego podejścia do skalowania pracy zwinnej. Mamy takie doświadczenie, że praktykowaliśmy skalowanie jeszcze przed pojawieniem się frameworków, co daje nam przekonanie, że najlepiej podchodzić do tego tematu ewolucyjnie. Oczywiście można inspirować się różnymi metodami, ale wciąż uważamy, że to może być pułapka. Zachęcamy do dopasowywania rozwiązań do konkretnego kontekstu organizacji. Na zakończenie tego rozdziału poniżej wskażemy konkretne praktyki, które sami byśmy zastosowali. Jednak nie traktuj ich jako gotowego zestawu czy procedury, ponieważ każda organizacja ma swoje specyficzne potrzeby. Warto je dopasować do odwagi, możliwości oraz dojrzałości zespołów. Te czynniki mogą sprawić, że w jednej organizacji dane praktyki będą miały sens, a w innej już nie. Proponowane praktyki pracy wielu zespołów nad jedną inicjatywą 1. Jasny i wyraźny cel inicjatywy Jasny i wyraźny cel inicjatywy ma za zadanie spajać myślenie ludzi na temat tego, co tak naprawdę jest do zrealizowania. Rekomendujemy tę praktykę, aby uniknąć rozjazdu priorytetów w organizacji i zapobiec rozszerzaniu budżetu czy zakresu projektu. Jasne określenie celu to nasz absolutny klasyk, punkt wyjścia. Tak jak dla pojedynczego zespołu potrzebujemy sensownego celu, tak samo ta praktyka ma zastosowanie w przypadku współpracy wielozespołowej. Ten cel może stać się mantrą, przypomnieniem, o co wszystkim zespołom chodzi. Tak jak wspomnieliśmy, cele dla zespołów mogą być jasne, ale w przypadku inicjatyw wielozespołowych może się okazać, że dla danego zespołu priorytety się zmieniają. Na przykład zespół rozwijający swój kawałek produktu może mieć swoją road mapę, ale gdy pojawia się większa, ogólnofirmowa inicjatywa, może być konieczne wstrzymanie pracy nad dotychczasowymi zadaniami i skupienie się na wspólnym celu. Ważne jest, żeby ten cel był jasny i zrozumiany przez wszystkich, aby nie powstały sytuacje, w których zespoły realizują równolegle swoje cele, udając, że współpracują nad czymś ogólnofirmowym. Jeśli inicjatywy mają się udać, wszyscy powinni realizować wspólny cel. 2. Budżetowanie przyrostowe Chodzi o uruchamianie budżetu na wczesnym etapie projektu, ale nie na całą inicjatywę, z góry na wiele miesięcy czy lat. Zamiast tego, podobnie jak fundusze inwestycyjne w start-upy, otrzymujecie pierwszą pulę finansowania, która pokrywa początkowe etapy. Takie podejście jest oszczędne i nastawione na szybkie wyniki, a kolejne rundy inwestowania są przyznawane w miarę osiągania celów. Ta praktyka jest istotna, ponieważ wielozespołowe inicjatywy niosą ryzyko przekroczenia budżetów, zakresu czy harmonogramu. Dlatego ważne jest, by jasno zakomunikować wszystkim zespołom, że dostaną tylko fundusze na początek, a dalsze finansowanie zależy od wyników. Należy unikać komfortowego podejścia, które może prowadzić do opóźnień, ponieważ czas jest kosztowny przez cały okres trwania projektu. Ważne jest, aby projekt realizować małymi krokami, zgodnie z uruchamianym finansowaniem.Warto pokazać, że rozumiemy cele biznesowe, że ogarniamy technologię, a co ważne, szczególnie przy skalowaniu, potrafimy ze sobą współpracować. Oczekiwanie, że powstanie coś namacalnego, stanowi doskonały pretekst do sprawdzenia i zarządzania wszystkimi ryzykami. 3. Dedykowany zespół pod inicjatywę Trzecia praktyka, którą rekomendujemy, to stworzenie dedykowanego zespołu pod konkretną inicjatywę. Może to być sprzeczne z tradycyjnym podejściem, w którym zespoły odpowiadają za określone obszary lub produkty. Często pojawia się pokusa, by przypisać część zasobów istniejących zespołów do realizacji wspólnej inicjatywy. Proponujemy jednak odwrotne podejście: zamiast tego, utwórz zespół dedykowany tej inicjatywie, aby uniknąć rywalizacji o czas i zasoby. Takie podejście zapewnia pełne skupienie na zadaniach, które muszą zostać wykonane, eliminując konieczność dzielenia uwagi między konkurujące inicjatywy. W najlepszym przypadku, zamiast angażować wiele zespołów do jednej inicjatywy, wyciągniemy po dwie, trzy osoby z kilku zespołów, które normalnie musiałyby współpracować, i stworzyć dedykowany zespół skoncentrowany wyłącznie na tym przedsięwzięciu.  Wiemy, że może to być sprzeczne z zasadą stałych zespołów, które są skupione na konkretnych produktach lub obszarach, ale w tym przypadku zachęcamy do rozważenia przełamania tej zasady, aby zapewnić pełne skupienie na realizacji danej inicjatywy.Zdajemy sobie sprawę, że ta praktyka może być sprzeczna z zasadą tworzenia stałych zespołów, które są przypisane do konkretnych produktów, obszarów lub systemów. Niemniej jednak, zachęcamy do rozważenia przełamania tej zasady, by stworzyć zespół dedykowany wyłącznie realizacji tej inicjatywy, co pozwoli na pełne skupienie się na jednym celu i zminimalizowanie rozproszenia. 4. Dobór najlepszych ludzi z dostępnych w organizacji Kolejna praktyka, o której mówimy, dotyczy doboru ludzi i polega na wybraniu najlepszych osób dostępnych w organizacji. W przypadku przedsięwzięć wymagających pracy wielu zespołów, które mają szczególne znaczenie biznesowe, warto bardzo starannie przeanalizować dostępne zasoby i wybrać te osoby, które mają największy wpływ na powodzenie projektu. Szczególnie istotne jest, aby wybrać osoby w funkcjach kluczowych, liderskich, Osoba zarządzająca produktem, w tego typu przedsięwzięciach rośnie również potrzeba dobrego architekt, oraz osoby na innych liderskich stanowiskach mogą mieć ogromny wpływ na sukces. Warto, aby osoby odpowiedzialne za tworzenie struktury wielozespołowej w organizacji rozważyły selekcję najbardziej odpowiednich kandydatów do tego przedsięwzięcia, by minimalizować ryzyko i zwiększyć szanse na jego powodzenie. Za tą praktyką doboru najlepszych ludzi kryje się jednak pewne zagrożenie. Jeśli stworzymy zespół z samych „gwiazd”, mogą pojawić się trudności związane z ich współdziałaniem. Może to prowadzić do problemów z ego, rywalizacją o to, czyje pomysły będą dominować, czy które decyzje będą priorytetowe. Przy tworzeniu takiego zespołu, warto szczególną uwagę zwrócić na proces grupowy oraz jego facylitację. Ważne jest, aby zespół, który początkowo może mieć różne interesy, z czasem stał się spójną grupą. Należy działać w krótkich okresach, raczej myśląc w kategoriach tygodni niż miesięcy, by stopniowo budować efektywną współpracę. 5. Jeden lider biznesowy decydujący o priorytetach Kolejną praktyką jest wskazanie jednej osoby, która będzie odpowiedzialna za podejmowanie decyzji i wyznaczanie priorytetów, pełniąc rolę lidera biznesowego. Ta osoba powinna pełnić funkcję kompasu lub latarni morskiej, wskazując właściwą drogę. W zależności od struktury organizacyjnej, może to być Product Owner, Product Manager, Project Manager lub inna rola, ale najważniejsze, żeby była to jedna osoba, która posiada autorytet, wizję i asertywność, oraz jest w stanie skutecznie poprowadzić całą inicjatywę. Podkreślamy, że kluczowe jest, aby była to jedna osoba odpowiedzialna za decyzje, ponieważ w organizacjach z wieloma dobrze działającymi zespołami może być kilka osób liderskich. Jeśli nie zostanie wyraźnie wskazana, namaszczona ta jedna osoba do podejmowania decyzji, istnieje ryzyko, że powstanie komitet produktowy, który podejmie decyzje kompromisowe lub niejednoznaczne, zamiast skupić się na klarownym celu i wartości.  W idealnym scenariuszu, p

Praca nad wieloma produktami jednocześnie w jednym zespole może być wyzwaniem. Jak sobie z tym poradzić? Przeczytaj 7 praktycznych wskazówek, które pomogą Twojemu zespołowi lepiej organizować pracę i zwiększać wydajność. Porządny Agile · Jak radzić sobie z wieloma produktami w jednym zespole? Spis treści Skup całą organizację na priorytetach i zredukuj liczbę otwartych tematówZmniejsz liczbę tematów przekazywanych do zespołów jednocześnie Zreorganizuj zakres odpowiedzialności zespołów, aby obejmowały jeden konkretny produktRealizuj inicjatywy produktowe w sposób sekwencyjnyWyodrębniaj esencję z tego, co jest do zrobieniaTwórz dynamiczne podzespoły, skupione na wybranych obszarachRozwijaj bardziej uniwersalny profil kompetencyjny członka zespołuA co jeśli powyższe porady to za mało?FAQ: Jak radzić sobie z wieloma produktami w jednym zespole?📄Transkrypcja podcastu „Jak radzić sobie z wieloma produktami w jednym zespole?„ Skup całą organizację na priorytetach i zredukuj liczbę otwartych tematów To fundamentalne zagadnienie, dlatego rekomendujemy rozpoczęcie od najwyższego szczebla. Działania na niższych poziomach, takich jak zespoły, mogą nie być tak skuteczne, jeśli nie rozwiążesz problemu u źródła. Tym źródłem jest strategia organizacji i jasna wizja tego, co ma być realizowane oraz dlaczego wybrane są konkretne inicjatywy. Redukcja liczby otwartych tematów na najwyższym poziomie to najbardziej systemowy i sensowny krok, jeśli chcesz ograniczyć liczbę inicjatyw w zespołach. Mamy przykład z naszego doświadczenia zawodowego, kiedy uczestniczyliśmy w konkretnych warsztatach strategicznych. Wraz z całym zarządem analizowaliśmy strategię naszego ówczesnego produktu i porównywaliśmy ją z kluczowymi konkurentami, względem których chcieliśmy się pozycjonować. Wsparci przez doświadczonych mentorów, zrozumieliśmy, że zarządzanie strategiczne polega na podejmowaniu kluczowych decyzji dotyczących tego, co będzie naszą przewagą konkurencyjną. Łączy się to z pełną świadomością rzeczy, które będą też słabsze z naszej strony.  Dzięki tym warsztatom i świadomej, wspólnej decyzji o tym, na czym się skupiamy i co będzie cenione przez rynek oraz klientów, stworzyliśmy solidny fundament. Na jego podstawie mogliśmy wyznaczyć konkretne inicjatywy produktowe i określić, na czym poszczególne zespoły powinny się skupić. W tej samej organizacji, zanim doszło do tej strategicznej rozmowy, przez kilka lat realizowano dość przypadkowe projekty. Przynosiły one wartość biznesową, generowały zyski i były sensowne z rynkowego punktu widzenia, ale pochodziły z bardzo różnych kategorii. W efekcie generowały dużą różnorodność wątków podejmowanych przez zespoły. Ustalenie strategicznych priorytetów i wybór kluczowego aspektu, na którym skupia się cała organizacja, pozwoliły łatwo wyznaczyć priorytety dla poszczególnych zespołów. Zmniejsz liczbę tematów przekazywanych do zespołów jednocześnie  Jeśli nie udało się osiągnąć zgody, o której wspominaliśmy w powyższej historii, i wciąż istnieje szeroka lista tematów oraz inicjatyw do realizacji przez zespoły, proponujemy ograniczenie liczby tematów przekazywanych jednocześnie. Chodzi o świadomość na poziomie najwyższego kierownictwa, że przekazywanie wielu tematów naraz niekoniecznie poprawi efektywność pracy. A w szczególności nie sprawi, że tematy zostaną dostarczone wcześniej. Sensownym punktem wyjścia może być umowa, że jeden zespół otrzymuje jeden konkretny cel na raz. Ten cel nie musi oznaczać pojedynczego elementu w produkcie; może obejmować wiele zadań do zrealizowania w ramach konkretnego produktu. Jednak wciąż poruszamy się w wyselekcjonowanym, konkretnym obszarze. Narzędziowo najczęściej przekłada się to na roadmapę skupioną na celach, gdzie cele są realizowane sekwencyjnie. Nawet jeśli organizacja nie ma w pełni przemyślanej strategii lub nie jest ona wystarczająco wyrazista, warto, aby zarządzający produktem, kluczowi sponsorzy czy menedżerowie większych obszarów skupili uwagę zespołu na jednym celu w danym momencie. Gdy ten cel zostanie zrealizowany w satysfakcjonujący sposób, można przejść do kolejnego. Nawet jeśli cele są ze sobą luźno powiązane, ważne jest, aby zespół mógł pracować nad nimi w bardziej skoncentrowany sposób. W praktyce oznacza to stworzenie roadmapy skupionej na celach. Jest to coś innego niż roadmapa z planowanymi funkcjami czy cechami produktu lub planem realizacji prac. Roadmapy często kojarzą się z datami, ale w tym przypadku wyobrażam sobie roadmapę przypominającą drzewko rozwoju technologii w Cywilizacji. W takim drzewku najpierw skupiamy się na rozwoju metalurgii, a potem zmieniamy sposób zbierania owoców. Tę analogię można przenieść na Twój produkt. Zreorganizuj zakres odpowiedzialności zespołów, aby obejmowały jeden konkretny produkt Zakładamy tutaj, że mnogość jednocześnie realizowanych zadań wynika z nieoptymalnie ustalonych granic odpowiedzialności zespołu. Może warto ponownie przedyskutować, czy zespół nie obejmuje zbyt dużego obszaru lub nie jest przypisany do niego w niefortunny sposób. Bo być może właśnie to skutkuje koniecznością jednoczesnej realizacji kilku tematów. W efekcie w zespole pojawia się więcej niż jeden pilny priorytet, więc dwie poprzednie porady nie mogą zostać zastosowane. Jak to może wyglądać w praktyce? Pomagaliśmy pewnej organizacji w usprawnieniu funkcjonowania zespołów, aby osiągnąć lepsze wyniki biznesowe. Zespoły te były zorganizowane wokół technologii. Powodowało to, że nawet drobna, czysto biznesowa zmiana wymagała zaangażowania wielu zespołów, zanim użytkownicy mogli z niej skorzystać. Management postanowił więc zreorganizować zespoły tak, aby nie były one skupione na konkretnej technologii, lecz na określonych obszarach biznesowych. Powstała konkretna tabela w Excelu, która proponowała, jakie to mogłyby być obszary biznesowe. Równocześnie zespoły przygotowały listę tematów technologicznych, nad którymi pracują. Na tej podstawie rozpoczęła się wieloetapowa, trwająca kilka tygodni dyskusja na temat najlepszego sposobu przeorganizowania się. Celem było to, aby zespoły mogły maksymalnie skoncentrować się na konkretnym produkcie, wykorzystując jednocześnie posiadaną wiedzę technologiczną. Mile widziana była też minimalizacja zmian w składzie zespołów. Oczywiście nie było to w pełni możliwe, więc wprowadzona zmiana uwzględniała, że niektóre osoby musiały zmienić zespół. Pojawiły się też nowe odpowiedzialności technologiczne w zespołach, a niektóre dotychczasowe obowiązki zostały przekazane innym zespołom. Z naszego doświadczenia udziału w kilku takich sytuacjach wynika, że nie ma gotowej odpowiedzi na to, jak podzielić zespoły. Nawet podział według kryteriów biznesowych to dość ogólne stwierdzenie. Doświadczenie podpowiada nam, że organizacje wypracowują odpowiedni dobór produktów iteracyjnie, najczęściej w trakcie dłuższych dyskusji, uwzględniając wiele czynników. Co ważne, prawdopodobnie za pierwszym razem nie uda się osiągnąć idealnego i trwałego efektu. Dlatego warto z góry założyć, że sposób podziału będzie doskonalony w przyszłości. A może organizacja przejdzie na tryb ciągłego, elastycznego reorganizowania zespołów? Najczęściej produkt się zmienia a firma decyduje się dostosować się do nowych rynków czy trendów. Realizuj inicjatywy produktowe w sposób sekwencyjny Zbliżamy się tutaj do bardziej realistycznego podejścia, może nawet nieco pesymistycznego. Załóżmy, że poprzednich zaleceń nie udało się wdrożyć lub nie przyniosły one pełnych oczekiwanych efektów. Nawet jeśli na poziomie strategii, zadań czy struktury organizacyjnej panuje pewne zamieszanie, wciąż można wiele zrobić na poziomie osoby decydującej o priorytetach w zespole. W niektórych zespołach taką osobą jest Product Owner, w innych Product Manager. Może postanowić, że mimo mnogości zleceń, będą one realizowane w danym zespole w sposób sekwencyjny, czyli „po kolei”. Najpierw jedna rzecz – ta najważniejsza lub najpilniejsza – a dopiero potem kolejne. Dzięki temu ogranicza się wielozadaniowość, minimalizuje przełączanie kontekstu i być może przyspiesza realizację tego, co jest naprawdę istotne. Ważne jest, aby osoba na ww. wspomnianym stanowisku wykazała się odwagą i asertywnością w odmawianiu. Konieczne będzie zatrzymanie pewnych inicjatyw. Ważne też może być wyraźne wskazanie, co musi poczekać i co zostanie zrealizowane w dalszej kolejności. Pozwoli to stworzyć przestrzeń na realizację tego, co w danym momencie jest najważniejsze. Trudno jednoznacznie określić, co jest w danej chwili najważniejsze. Może to być najbardziej obiecująca inicjatywa, pilne spłacenie długu technologicznego (na przykład z powodu utraty wsparcia dla używanej technologii) lub dostosowanie się do konkretnych, nieprzesuwalnych terminów (np. nadchodzące zmiany prawne). To podejście nie jest intuicyjne; wciąż pokutuje przekonanie, że jeśli robi się wiele rzeczy naraz, ukończy je szybciej. Literatura i praktyka są tu bezlitosne. Mantra „zacznij kończyć, przestań zaczynać” jest naszym zdaniem czymś, na czym warto się oprzeć. Wyodrębniaj esencję z tego, co jest do zrobienia Jedną z przyczyn, dla których zespoły mają trudności z realizacją wielu inicjatyw produktowych jednocześnie, jest za duża wielkość inicjatyw. Pod naporem priorytetów lub spraw, które nie mogą już czekać, pojawia się wielozadaniowość, która zaczyna być uciążliwa. Zdolność do dzielenia zadań jest umiejętnością, której trzeba się nauczyć. Zespoły, które to potrafią są w stanie szybko dostarczać mniejsze fragmenty inicjatywy. Dzięki temu osoby zarządzające priorytetami mogą podjąć decyzję, co zrobić z pozostałą częścią. Czy ją wstrzymać i przystąpić do kolejnej inicjatywy, czy może całkowicie z niej zrezygnować, jeśli tak wskaże feedback z rynku? Czasem okazuje się, że po dostarczeniu pewnej części, reszta nie jest już tak bardzo potrzebna. Klasycznym przykładem, który niezmiennie obserwujemy, jest przepisywanie systemu z powodu zmiany platformy czy technologii. Bardzo często takie przepisyw

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 o tym, jak powinna wyglądać taka współpraca ze Scrum Masterem z perspektywy dowolnego członka Zespołu Scrumowego. Jeśli zarządzasz Scrum Masterami lub jesteś członkiem Zespołu Scrumowego, to ten materiał jest właśnie dla Ciebie. Scrum Masterzy też znajdą tu przydatne informacje. Pomożemy Ci zrozumieć, jak skutecznie komunikować swoją rolę i odpowiedzialności. Porządny Agile · Czego oczekiwać od Scrum Mastera? Spis treści Kiedy Scrum Master poprawnie realizuje swoją odpowiedzialność?Co zrobić, jeśli sposób pełnienia roli SM wymaga usprawnienia?FAQ: Czego oczekiwać od Scrum Mastera?📄Transkrypcja podcastu „Czego oczekiwać od Scrum Mastera?” Kiedy Scrum Master poprawnie realizuje swoją odpowiedzialność? 1. Inicjuje rozmowę o swojej “ofercie”  To absolutna podstaw pracy! Oczekujemy, że Scrum Master, rozpoczynając współpracę z zespołem lub firmą, potrafi opowiedzieć: czym się zajmuje, co planuje robić, jakie techniki stosuje i na jakich zasadach będzie współpracować. Scrum Master powinien wyjaśnić, na czym polega jego funkcja. Umiejętność przedstawienia swojej oferty świadczy o tym, że jest ona dobrze przemyślana. Dobra oferta wykracza poza wsparcie zespołu tylko podczas wydarzeń scrumowych. Pokazanie tego, co faktycznie może zrobić w organizacji, jest czymś, do czego zawsze zachęcamy. 2. Edukuje zespół w temacie zwinności i Scruma Oczekujemy, że Scrum Master potrafi wyjaśnić nie tylko sam framework Scrum, który w wielu firmach stanowi podstawę pracy zespołów. SM musi także rozumieć czym jest zwinność. Popularność Scruma sprawiła, że wiele technik i praktyk jest kategoryzowanych jako scrumowe. Może prowadzić to do zapomnienia o podstawowych zasadach wynikających z podejścia zwinnego lub inspirowanych innymi metodami pracy. Ważne jest, aby Scrum Master rozumiał te zasady i umiał je sensownie wytłumaczyć zespołowi. W praktyce oznacza to edukowanie zespołu w wielu obszarach. Przykładowo może być to być samozarządzanie — koncept, w którym zespół sam organizuje swoją pracę bez potrzeby koordynatora czy managera. Scrum Master powinien umieć wyjaśnić temat Celu Sprintu, podpowiedzieć, jak go zastosować, i przeprowadzić zespół przez niezbędne zmiany. SM zna też techniki zarządzania Backlogiem Produktu, metody priorytetyzacji czy sposoby opisu elementów Backlogu. Oczekujemy, że Scrum Master potrafi zaproponować praktyki odpowiednie do problemów zespołu, przedstawić przykłady, szablony czy modele. Ważne jest także, aby umiał wdrożyć te rozwiązania w życie. Oznacza to aktywną pomoc zespołowi w ich zastosowaniu, doradztwo, jak zrobić to po raz pierwszy i jak udoskonalić docelowy proces. Jeśli Scrum Master mówi: „Nie umiemy tego robić”, to oznacza, że to przede wszystkim SM powinien nadrobić braki w edukacji. 3. Sprawia, że wydarzenia i artefakty scrumowe mają sens Z bólem serca czasami słyszymy od zespołów stwierdzenia typu: „Nasze Daily nie ma sensu”, „Nie warto realizować Retrospektywy„. Czasem spotyka się też stwierdzenie: „To, co mamy w Backlogu Produktu, jest zupełnie bezcelowe i nie ma sensu tego uzupełniać”. Dla nas to sygnał, że jest coś do poprawy. Wszystkie elementy Scruma – praktykowaliśmy i obserwowaliśmy to – mają sens. To Scrum Master potrafi to przekazać zespołowi zrozumiałym językiem i sprawić, by ten sens pojawił się w zespole. Zwłaszcza zespół początkujący lub mający swoje wyzwania może wykonywać te elementy niedoskonale. Od Scrum Mastera oczekujemy, że korektami i podpowiedziami sprawi, że poszczególne praktyki w Zespole Scrumowym złożą się w całość. Pierwszym krokiem z perspektywy Scrum Mastera powinno być zrozumienie wszystkich niuansów Scruma. Tylko wtedy będzie w stanie komentować wydarzenia i artefakty oraz ich celowość i sensowność. Najpierw trzeba odrobić lekcję pod tytułem: „Po co tak naprawdę to robimy? Dlaczego ten konkretny element Scruma jest tu, gdzie jest? Dlaczego powinniśmy na niego zwracać uwagę?” To oczywiście prowadzi do rekomendacji, aby zadbać o edukację i naprawdę zrozumieć, dlaczego te konkretne elementy zostały wymyślone. Oznacza to rozmawianie z praktykami, uczestnictwo w szkoleniach prowadzonych przez osoby, które faktycznie to rozumieją. To tylko przykłady działań, które można podjąć, aby uzyskać takie zrozumienie. 4. Zapewnia, że zespół się regularnie usprawnia Ciągłe doskonalenie jest absolutnym fundamentem zarówno podejścia zwinnego, jak i Scruma. Zadbanie o to, by usprawnienia faktycznie miały miejsce, jest jedną z najważniejszych funkcji Scrum Mastera. Ważne jest, aby te usprawnienia były rzeczywiście realizowane przez zespół zgodnie z ustaleniami. Ponadto warto upewnić się, że dotyczą one faktycznie obszarów, które poprawią pracę zespołu, a nie są jedynie wygodnymi tematami zastępczymi. Jak możemy rozpoznać, że Scrum Master wspiera zespół w usprawnianiu? Przede wszystkim poprzez organizację Retrospektyw Sprintu. Niestety, w wielu zespołach to wydarzenie scrumowe jest pomijane lub traktowane bardzo powierzchownie. Dobry Scrum Master sprawia, że zespół rozumie cel Retrospektywy. Każdy uczestnik rozumie jej przebieg i wie, czego się od niego oczekuje podczas tego spotkania. W efekcie cały zespół dochodzi do konkretnych wniosków. Retrospektywa jest spotkaniem z którego Zespół wychodzi z poczuciem: „Tak, od najbliższego Sprintu wprowadzimy jedną, dwie rzeczy, które realnie zmienią naszą pracę”. Jeśli u Ciebie wydarzenie to jest niedoskonałe, sprawdź nasz webinar jak powinna wyglądać porządna Retrospektywa Sprintu. 5. Doprowadza do usuwania przeszkód Przeszkody w Scrumie to pojęcie występujące w sytuacji, w której Zespół spowalnia pracę i ma trudności w realizacji celów. Może to też być ewidentny postój w miejscu, w którym Zespół nie jest w stanie uzyskiwać jakiegokolwiek postępu.  Scrum Master dąży do usuwania tych przeszkód. Może to robić samodzielnie. Może także przysłużyć się zespołowi poprzez świadomą eskalację problemów do odpowiednich osób poza zespołem lub wspierać innych członków zespołu w ich rozwiązywaniu. Na przykład poprzez przypominanie o problemie, nieignorowanie go, dostrzeganie jego istnienia i w ten sposób zachęcanie całego zespołu do wspólnego znalezienia rozwiązania. Dobrego Scrum Mastera w tym aspekcie poznamy po tym, że rejestr przeszkód istnieje i jest widoczny. Nie jest to coś, co Scrum Master trzyma dla siebie i do czego zespół nie ma dostępu. Powinno być wręcz przeciwnie: to są przeszkody zespołowe, które Scrum Master będzie próbował rozwiązać samodzielnie lub z pomocą innych, ale będzie dbał o to, by tematy posuwały się naprzód. Ważne jest także, aby rozmawiać o faktycznych, źródłowych przyczynach problemu, a nie tylko o powierzchownych aspektach. Trzeba zagłębić się w problem i zrozumieć, z czego on tak naprawdę wynika. 6. Zwraca uwagę zespołu na jego efektywność Kiedy mówimy o efektywności, mamy na myśli relację między efektami uzyskanymi przez zespół a kosztami poniesionymi na ich osiągnięcie. Nie chodzi o to, jak bardzo ludzie są zajęci, zapracowani czy jak szybko pracują — to nie ta droga. Istotna jest prosta zależność między efektami a kosztami.  Choć ta relacja jest prosta, sposób jej mierzenia nie zawsze jest łatwy, więc dla każdego zespołu może to wyglądać inaczej. W zależności od produktu, firmy czy branży, w której zespół działa, efekty mogą mieć różny charakter.  Zadaniem Scrum Mastera jest zwracanie uwagi na to, czy w ogóle mówi się o efektywności. Ważna jest współpraca z Product Ownerem, aby cały Zespół Scrumowy był świadomy, gdzie leży wartość biznesowa, na czym firma zarabia i dlaczego klienci czy użytkownicy chcą konkretnego elementu. To strona wyników, ale równie istotna jest rozmowa o kosztach. Czy zespół pracuje tak wydajnie, jak powinien? Czy są możliwości zaoszczędzenia pewnych kosztów? Nie chodzi tu tylko o koszty ludzkie. Każdy zespół ponosi również koszty związane z infrastrukturą, licencjami, niepotrzebnymi działaniami, niską jakością czy nieefektywnymi praktykami. Wszystko to kumuluje się, powodując, że koszt wytworzenia efektu jest wyższy niż mógłby być. Ważne, aby Scrum Master poruszał te kwestie z zespołem —  uświadamiał, wyjaśniał, pokazywał pewne mierniki i zadawał trudne pytania, które skłaniają do refleksji. Dzięki temu zespół nie będzie realizował bezmyślnie zadań bez wartości ani wykonywał ich w sposób bardzo kosztowny. Więcej na ten temat znajdziesz na blogu Kuby, gdzie powstała dedykowaną stronę poświęconą efektywności: https://www.kubaszczepanik.pl/efektywnosc/ 7. Wyjaśnia intencje swoich działań Ostatnie oczekiwanie wobec Scrum Mastera dobrze realizującego swoją rolę stanowi pewnego rodzaju klamrę. Wszystkie poprzednie punkty, które omówiliśmy, muszą być zrealizowane w określonym stylu. Scrum Master powinien wyjaśniać intencje swoich działań. Mamy duży problem ze Scrum Masterami, którzy zachowują się enigmatycznie i bez wyraźnego pytania nie potrafią powiedzieć, dlaczego coś proponują, jaką technikę stosują, zadają pytania czy proszą o wykonanie konkretnej instrukcji. Od dobrego Scrum Mastera oczekuję, że bez konieczności pytania potrafi powiedzieć: „Robimy to i to, ponieważ… Chcę coś osiągnąć, chcemy jako zespół coś osiągnąć.” Odważnie i szczerze deklaruje pewne rzeczy i oczekiwania, pokazuje swój plan działania. Nie ma ukrytej agendy, manipulacji czy tajemnicy, której zespół nie jest w stanie zrozumieć. To jest istotne, aby Scrum Master nie kreował wizerunku osoby z tajnym planem czy ukrytą agendą, ani nie sprawiał wrażenia nadrzędnej roli wobec zespołu, gdzie on wszystko wie i mówi, jak ma być, a reszta ma tylko słuchać. Intencje Scrum Mastera powinny być maksymalnie jasne i transparentne dla zespołu. Zespół powinien doskonale rozumieć, że konkretne pytania, sugestie czy propozycje nie wynikają z osobistych kaprysów Scrum Mastera, który przeczytał mądrą książkę i teraz udaje, że wie lepiej.

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 obszarach, które są w ich zasięgu, co prowadzi do efektywniejszych usprawnień i zwiększenia satysfakcji z pracy. Dowiesz się też jakie zastosowanie ma Circle of influence w Retrospektywie oraz innych kontekstach, takich jak zarządzanie zależnościami czy planowanie zmian w organizacji. Porządny Agile · Circle Of Influence Ostatnio podczas warsztatów przeprowadziliśmy dyskusję z pewnym zespołem, który był przekonany, że nie ma już niczego, co można usprawnić. Po głębszym zbadaniu tematu doszliśmy do wspólnego wniosku, że istnieją obszary do poprawy, ale nie leżą one w zasięgu mocy sprawczej zespołu. Próby rozmowy o tych kwestiach były frustrujące, więc zespół postanowił całkowicie zrezygnować z Retrospektyw. Spis treści Czym jest Circle of influence?Jakie problemy rozwiązuje Circle of influence?Jak z tego skorzystać?Do jakich działań można użyć Circle of influence?FAQ: Circle of influence📄Transkrypcja podcastu „Circle of influence” Ten przypadek był pojedynczym wydarzeniem z warsztatu, ale jest znamienny, takie sytuacje spotykamy częściej. Kiedy zespół ma poczucie, że nic nie da się poprawić, zwłaszcza w obszarach poza jego kontrolą, jednym z rozwiązań, które najczęściej proponujemy, jest narzędzie zwane Circle of influence. Czym jest Circle of influence? Koncept Circle of influence został stworzony przez psychologa Kurta Lewina, a później spopularyzowany i nieco zmodyfikowany przez Stephena Coveya, autora znanych koncepcji związanych z nawykami efektywnego działania. Będziemy używać terminu „Circle of influence” jako nazwy narzędzia, mimo że istnieje polskie tłumaczenie „krąg wpływu.” Trzymamy się angielskiej nazwy, ponieważ w biznesowym obiegu jest ona częściej używana, a polskie tłumaczenia, zwłaszcza w szczegółach, nie zawsze oddają dokładnie niuanse tej koncepcji. Czym dokładnie jest ta koncepcja? Zakłada ona, że istnieją trzy poziomy naszego wpływu:  nie mamy żadnego wpływu. pełny wpływ, częściowy wpływ, W psychologicznych korzeniach tej koncepcji mocno wybrzmiewa założenie, że niektóre osoby poświęcają zbyt dużo uwagi na rzeczy, na które nie mają wpływu. To powoduje stres, blokuje działanie, wywołuje poczucie bezsilności i brak satysfakcji. Psychologiczny aspekt tej koncepcji ma na celu przekierowanie uwagi na rzeczy, na które faktycznie mamy wpływ, i skupienie się na nich, zamiast na tych, które są poza naszą kontrolą. W zespołach zwinnych stosujemy to narzędzie, aby pobudzić refleksję nad możliwymi zmianami oraz nad tym, jaki wpływ zespół ma na swoje otoczenie. Wracając do historii z początku, są zespoły, które koncentrują się na dużych niedoskonałościach znajdujących się poza ich strefą wpływu i skupiają się na tym, że nie mogą tych elementów zmienić. Jednocześnie zaniedbują obszary, na które mają wpływ, zarówno bezpośredni, jak i pośredni, i gdzie faktycznie mogliby dokonać zmian. Obejrzyj nagranie rozmowy Jakie problemy rozwiązuje Circle of influence? Przytoczymy ci po jednym, celowo różnym, przykładzie, aby pokazać, gdzie zastosowalibyśmy Circle of influence w konkretnych sytuacjach biznesowych. Pierwszym przykładem jest praca z grupą liderów, którzy starali się poprawić współpracę między sobą, aby skuteczniej i bardziej skoordynowanie przeprowadzić zmianę w organizacji. Zapytani o ostatnie usprawnienia, które zrealizowali, przedstawili różne tłumaczenia, że „nie da się”, „jest szklany sufit”, „próbowaliśmy wielokrotnie”, „odbijaliśmy się od organizacji” i generalnie nie ma poprawy. Wprowadzenie Circle of fnfluence pokazało, że tematy, które próbowali rozwiązywać, były poza ich strefą wpływu. Rekomendacja dla tego zespołu liderów polegała na tym, aby skupili się na rzeczach, na które mają częściowy, a zwłaszcza pełny wpływ i skierowali tam całą swoją energię. Zastanowili się się, jak organizują się jako liderzy, jak pracują z zespołami i jak wspierają procesy w organizacji. W wymienionych obszarach mieli możliwość wprowadzenia realnych zmian, bo  właśnie tam mieli pełny lub częściowy wpływ. Kolejna historia wykorzystania Circle of influence wiąże się z pomocą pewnemu zespołowi, który pracował Scrumem od dłuższego czasu i był w tym naprawdę dobry. Zespół osiągał świetne wyniki, miał poczucie, że wiele poprawił, dobrze współpracował i kończył zadania, których się podejmował. Wiedzieli, że są już bardzo mocnym zespołem, jednak potrzebowali wsparcia, ponieważ zaczęło brakować im pomysłów na dalsze usprawnienia. Kiedy zagłębiliśmy się w temat, okazało się, że zespół łatwo wyliczał rzeczy, które można by zmienić, ale były to głównie zmiany o dużym kalibrze – organizacyjne, procesowe, dotyczące całej firmy. Byli na tyle zaawansowani, że widzieli potrzebę zmian na poziomie całej organizacji, choć w tej firmie jeszcze nie było na to gotowości. To prowadziło do pewnego marazmu w zespole – czuli się nieco lepsi od reszty, ale jednocześnie widzieli, że pewnych zmian obiektywnie nie da się na razie wprowadzić. Retrospektywy często kończyły się albo rozmowami o zmianach, które nie mogły się wydarzyć, albo na mało istotnych, zastępczych tematach, na które szkoda było czasu. Kuba przeprowadził dla nich Retrospektywę z użyciem Circle of influence. Zespół szybko zauważył, że są rzeczy poza ich strefą wpływu, które nie powinny być przedmiotem dalszej dyskusji oraz usprawnień. Zauważyli również obszary, na które mają przynajmniej częściowy wpływ i mogą spróbować je poprawić. Po tej Retrospektywie zespół poczuł zastrzyk nowej inspiracji i energii do dalszych usprawnień, które wcześniej im nie wychodziły bądź były poza ich zasięgiem. Jakie efekty daje wykorzystanie Circle of influence? Zyskujemy jasne zrozumienie, jaki mamy wpływ na daną sytuację Wiemy, jaki mamy wpływ na konkretny temat Inspirujemy się do dalszych usprawnień Wybieramy te usprawnienia, które są możliwe do wprowadzenia Zauważamy możliwość pośredniego wpływu na wybrane sytuacje Jak z tego skorzystać? Oryginalnie Circle of influence jest przedstawiane w literaturze jako zestaw zawierających się kręgów, co jest celowe i daje nazwę tej metodzie. Jednak równie dobrze można to zobrazować jako tabelkę czy grupy zagadnień, co jest równie skuteczne. Podstawą podejścia jest klasyfikowanie zagadnień otaczających daną osobę, zespół, czy całą organizację do trzech kategorii:  pierwsza kategoria to Circle of concern, czyli sprawy, które są istotne, ale na które nie mamy wpływu z perspektywy danej osoby lub zespołu Circle of oinfluence to zagadnienia, na które mamy częściowy lub pośredni wpływ Circle of control, czyli sprawy, które są całkowicie pod kontrolą danej osoby, zespołu lub organizacji i znajdują się w pełni w ich decyzyjności Na bazie takiej klasyfikacji, grupa lub osoba korzystająca z tego narzędzia może świadomie wybrać zagadnienia i skupić się na tym, co rzeczywiście można zmienić. W kolejnych krokach warto przejść do konkretnego planu działania, określając, co chcemy zrobić z tymi wybranymi zagadnieniami. Ciekawym wątkiem pobocznym, który często pojawia się przy wykorzystaniu Circle of influence, jest to, że w niektórych zespołach może wywołać bardzo żywą dyskusję na temat różnic w postrzeganiu wpływu. Ktoś może stwierdzić, że nie ma wpływu na proces wytwórczy, a inna osoba może odpowiedzieć, że jak najbardziej mamy wpływ, bo to od nas zależy, jak go stosujemy, albo możemy wpłynąć na niego pośrednio, wystarczy jedno słowo. Takie różnice zdań mogą być wyraźne i jeśli prowadzisz tego typu ćwiczenie w swoim zespole, zachęcamy cię, aby zatrzymać się na tym etapie. Warto wejść w lekką konfrontację, wymienić się argumentami, aby dać wybrzmieć różnym perspektywom i ustalić, jaka jest rzeczywistość. Circle of influence może ujawnić różnice między pesymistami i optymistami w zespole, i warto zadbać o to, by pesymiści nie dominowali narracji, twierdząc, że nic nie da się zmienić i że status quo musi być zachowane. Choć Circle of influence nie jest narzędziem stworzonym do tego celu, może dostarczyć cennych refleksji na temat różnic w postrzeganiu spraw w zespole, zwłaszcza gdy połączymy je z technikami facylitacji i poszerzaniem perspektyw. Do jakich działań można użyć Circle of influence? 1. Retrospektywa Sprintu w zespole Circle of influence może być konkretnym modułem lub elementem większego planu na Retrospektywę Sprintu. Widzimy tutaj idealne zastosowanie tego narzędzia po etapie generowania przemyśleń, na przykład listy tematów do poruszenia, problemów, które zespół dostrzega, czy pomysłów na zmiany. Jeśli tematów jest dużo i pojawia się poczucie, że niektóre z nich są absolutnie nieruszalne, Circle of influence może pomóc przefiltrować te tematy. Przepuszczając je przez trzy kręgi lub klasyfikacje, można szybko dokonać wstępnej selekcji: tematy, na które nie mamy wpływu, możemy odłożyć na później, a skupić się na tych, na które mamy pełny lub częściowy wpływ. Te właśnie warto dalej procesować, na przykład przez głosowanie czy selekcję. Może się okazać, że po tym etapie lista jest na tyle krótka, że można omówić wszystko dokładnie i głęboko.Jeśli temat etapu generowania nie jest Ci znany albo nie czujesz się komfortowo z tematem struktury Retrospektywy, to zdecydowanie polecamy sprawdzić nasz webinar „Porządna Retrospektywa Sprintu”. W nim omawiamy m.in. kroki i strukturę, które pozwalają na skuteczne przeprowadzenie Retrospektywy Sprintu. Webinar znajdziesz pod adresem porzadnyagile.pl/retro 2. Zarządzanie zależnościami zewnętrznymi w zespole Często zespoły domyślnie odpowiadają na pytanie, co można zrobić z zależnościami zewnętrznymi, stwierdzeniem: “właściwie nic nie możemy zrobić, bo to leży poza naszym obszarem wpływu.” Nasze doświadczenie pokazuje, że po głębszym zastanowieniu można zrobić więcej niż tylko stwierdzić brak wpływu. W praktyce może się okazać, że istnieją działania, na które mamy częściowy wpływ, na przykład zaangażowani

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 naszych hipotez. Mamy też dla Ciebie kilka rozwiązań, które pomogą poprawnie skonstruować Cel Sprintu. Porządny Agile · Dlaczego tak trudno ustalić Cel Sprintu? Cel Sprintu jest zobowiązaniem będącym częścią Backlogu Sprintu. Jest on ustalany przez Zespół Scrumowy podczas planowania Sprintu. Określa, co zespół chce osiągnąć w ramach Sprintu. Dobrze sformułowany Cel daje developerom pewną swobodę w doborze rozwiązania w trakcie Sprintu. Cel Sprintu pozostaje niezmienny przez cały Sprint, co zapewnia zespołowi skupienie, spójność współpracy i stały punkt odniesienia przez cały czas trwania Sprintu. Spis treści Powody problemów w konstruowaniu celu SprintuJak rozwiązać problemy w zbudowaniu celu Sprintu? FAQ: Dlaczego tak trudno ustalić Cel Sprintu?📄Transkrypcja podcastu „Dlaczego tak trudno ustalić Cel Sprintu?„ Powody problemów w konstruowaniu celu Sprintu 1. Brak zrozumienia czym jest Cel Sprintu To bardzo podstawowy, ale istotny problem. Obserwujemy, że brak dobrego zrozumienia, dlaczego Cel Sprintu jest obecny w Scrumie, prowadzi do problemów z jego praktycznym wykorzystaniem podczas Sprintu. Cel Sprintu jest narzędziem, które pozwala nam osiągnąć skupienie. Z natłoku różnych tematów, którymi moglibyśmy się zająć w trakcie Sprintu, wybieramy jeden określony kawałek – coś, co chcemy osiągnąć na koniec Sprintu, czy to funkcjonalnie, czy biznesowo. Cel Sprintu powinien być dla nas najistotniejszy i pomagać w podejmowaniu codziennych decyzji podczas pracy w Sprincie. 2. Założenie, że Cel dotyczy całego zakresu i wszystkich Developerów Mamy tutaj do czynienia z nadinterpretacją teorii, która mówi, że cel zapewnia skupienie i pozwala na współpracę. Choć to prawda, przesadne zrozumienie tego może prowadzić do myślenia, że Cel Sprintu musi pokryć 100% elementów wziętych do Sprintu, włącznie z tymi, które są nieco inne niż główne zadanie.  Podobnie problem może dotyczyć developerów. Jeśli zespół składa się z sześciu developerów, pięciu może realizować główne zadanie, ale szósty może zajmować się np. zadaniami utrzymaniowymi. W takich przypadkach zespoły próbują na siłę włączyć wszystkie zadania i wszystkich developerów do Celu Sprintu, co prowadzi do tworzenia celów zbyt ogólnych lub wieloelementowych. Naszym zdaniem jest to antywzorzec. Odwracając ten problem, Cel Sprintu nie musi pokrywać całego zakresu i nie musi dotyczyć każdego developera w danym momencie. Ważne jest, aby zrozumieć specyfikę danego zespołu i skupić się na głównym celu, który jest najistotniejszy dla Sprintu. 3. Poczucie, że jeśli coś nie jest w Celu Sprintu, to nie jest ważne Wyobraź sobie sytuację, w której zespół konstruuje Cel Sprintu i pewne prognozowane elementy z Backlogu Produktu wchodzą w jego zakres. Nagle ktoś mówi, że naprawa jakiegoś błędu jest również ważna, ale skoro nie ma jej w Celu Sprintu, to zespół nie będzie się na niej skupiać. Cel Sprintu ma wskazywać drogę, być drogowskazem, latarnią morską dla zespołu, ale to nie oznacza, że rzeczy spoza Celu Sprintu są kompletnie nieważne i można je zignorować. W praktyce może się zdarzyć, że rzeczy poza Celem Sprintu, gdy w trakcie Sprintu odkryje się problemy, mogą stać się kandydatami do renegocjacji. Jednak na etapie planowania Sprintu nie powinniśmy od razu zakładać, że czegoś nie zrobimy tylko dlatego, że nie jest w Celu Sprintu. 4. Realizacja Celów jest rozliczana przez management  Realizacja Celu Sprintu jest rozliczana przez management, co może być źródłem problemów. Dlaczego? Ponieważ zespoły zaczynają podejmować niewskazane negocjacje.  Jeśli zespoły są ściśle monitorowane i kontrolowane, ustalają taki Cel Sprintu, aby jak najszybciej go zaliczyć. Niestety, widzieliśmy na własne oczy, że jako Cel Sprintu formułowane jest coś, co można zrealizować w 1-2 dni. Oczywiście, zespół wykonuje wiele innych zadań, ale ma potencjał, aby wyznaczyć bardziej ambitny Cel Sprintu. Jednak zespoły są zachęcane przez management do tego, aby zawsze mieć wszystko „na zielono”. W rezultacie cel jest albo banalny, albo tak negocjowany, żeby go zawsze zaliczyć. To powoduje, że Cel Sprintu nie spełnia swojej podstawowej funkcji, a staje się narzędziem do unikania problemów i zapewnienia, że wszystko wygląda dobrze w raportach. Takie podejście jest zrozumiałe w korporacyjnym świecie, ale może być bardzo frustrujące dla Product Ownerów, którzy chcieliby stawiać bardziej ambitne cele. Ponadto, koncepcja pracy eksperymentalnej i przyrostowej całkowicie się rozmywa, ponieważ zespół skupia się na bezpieczeństwie i zaliczaniu celów, zamiast na faktycznym rozwoju i dostarczaniu wartości. 5. Brak pracy przyrostowej Dlaczego tak trudno ustawić sensowny Cel Sprintu? Jednym z głównych powodów jest brak pracy przyrostowej. Mówimy o sytuacji, w której zespół realizuje z góry założony zakres konkretnego produktu lub projektu, ale brakuje chęci poukładania tego w sensowne przyrosty. Na pierwszy rzut oka, patrząc na Backlog Produktu, może się wydawać, że jest on sensownie przemyślany i można z niego wyłonić Cele Sprintu. Jednak w rzeczywistości jest to po prostu lista rzeczy do zrobienia, a podczas planowania Sprintu trudno wyłapać z tej listy coś, co można zamknąć w sensowny Cel Sprintu. Problem tkwi w braku przyrostowości. Wiele zespołów ma trudności z formułowaniem Celów Sprintu, ponieważ Sprinty nie przynoszą przyrostów. Jest to wynik tego, że zadania są tak poukładane, że trzeba zrobić wszystko. Wybierane są nie te kombinacje realizacji zakresu, które dają przyrostowość, ale te, które z jakiegoś powodu ładnie pasują do planu. Problem polega na tym, że brakuje przyrostowości, a koncepcja robienia pełnych kroków i osiągania sensownych celów zanika. 6. Wiele równoległych wątków realizowanych w Sprincie To klasyczny problem, który najczęściej prowadzi do antywzorca, który nazywamy „wielocelem”. Oznacza to, że zespół ma w planie zrealizować funkcjonalność X, poprawić wskaźnik KPI ABC o Y oraz rozwiązać 10 błędów. Taki „wielocel” najczęściej można rozpoznać po wielu połącznikach w formule celu, gdzie wszyscy widzą i wiedzą, że to są dwie, trzy, cztery, a czasem nawet więcej wyraźnie odseparowanych zadań. Są one wzięte do Sprintu, zgodnie z decyzją Product Ownera, być może samodzielnie, a być może pod naciskiem interesariuszy, komitetów lub innych czynników. Na etapie planowania zespół łatwo odkrywa, że musi złapać wiele wątków. Product Owner nie jest skłonny do zmiany tej sytuacji. Ewentualnym mini rozwiązaniem jest uzgodnienie, że zespół wykonuje wiele różnych rzeczy, ale tylko jedna z nich trafia do Celu Sprintu. Jednak wówczas wracamy do problemów, które wcześniej wspomnieliśmy. 7. Produkt nie jest rozwijany poprzez cele Jeśli nie wykonuje się odpowiedniej pracy przed planowaniem Sprintu, nie mamy na myśli tylko procesu Refinementu, ale także bardziej wysokopoziomowej analizy, która pozwala spojrzeć na produkt z szerszej perspektywy, to później trudno jest określić Cel Sprintu. Jeżeli nie mamy jasno określonego sensownego Celu Produktu, bardzo trudno jest ustalić konkretne kroki, czyli Cele Sprintu, które będą nas prowadzić do tego Celu Produktu. Jeżeli Cel Produktu jest dla Ciebie interesującym tematem, odsyłamy Cię do odcinka 111 na stronie porzadnyagile.pl/111. 8. Backlog Produktu nie jest uporządkowany W skrajnych przypadkach dopiero na planowaniu Sprintu ustala się, co właściwie znajduje się w Backlogu. Często zespół dopiero ustala kryteria, dokonuje estymacji i dzieli zadania. Powoduje to, że są ważniejsze sprawy niż rozmowa o Celu Sprintu. Jeśli Backlog Produktu jest nieuporządkowany, prawdopodobnie nie było czasu na rozmowy o Celach Produktu jako całości, kolejnych większych krokach, przyrostach czy pomysłach na rozwój produktu. Najczęściej wynika to z braku wystarczającego czasu na Refinement. Jednym z pytań, jakie zadalibyśmy zespołowi mającemu problemy z Celami Sprintu, jest: „Jak wygląda wasz Backlog Produktu?” Na ile jest gotowy i jak daleko w przód jest zaplanowany? W dyskusjach, pracach i aktywnościach refinementowych widzimy silną korelację – nieuporządkowany Backlog powoduje trudności z planowaniem i ustalaniem Celu Sprintu. 9. Zespół rozwija wiele produktów albo projektów Kolejny problem, który uniemożliwia łatwe i skuteczne tworzenie Celu Sprintu, to sytuacja, w której zespół rozwija wiele produktów jednocześnie lub pracuje nad wieloma projektami.  W takiej sytuacji zespół jest traktowany jako zasób, do którego można wrzucać dużą liczbę różnych wątków, streamów czy kontekstów. Zwykle prowadzi to do tego, że pojedyncze osoby lub małe podgrupy (2-3 osoby) obsługują te wątki. Jeśli mamy kilka takich wątków na Sprint, nie jesteśmy w stanie stworzyć Celu Sprintu, który jest wspólny dla całego zespołu. Cel Sprintu powinien angażować większość zespołu, budując poczucie zespołowości i wspólnego dążenia do celu. Kiedy wątków jest wiele, wyklucza to możliwość stworzenia takiego celu, który daje wartość zespołowi i poczucie wspólnego osiągnięcia konkretnego celu. W skrajnym przypadku może to oznaczać, że każdy członek zespołu ma swój własny Cel Sprintu, ponieważ wątków jest tyle, ilu członków zespołu. To kompletnie się nie sprawdza.  10. Zespół nie tworzy kompletnego produktu  Zespół może być skoncentrowany na jednej specjalizacji technologicznej, podczas gdy produkt ma wiele warstw, obsługiwanych przez inne zespoły. Może to być też zespół składający się z wybranych kompetencji, ale niezdolny do stworzenia sensownego produktu jako całość. W takich przypadkach Cele Sprintu są zupełnie nieadekwatne. Możemy na przykład postawić serwis, ale to nie jest ani funkcjonalność, ani cel biznesowy. Jest to, tylko etap w rozwoju. Zespół może czuć, że sensowny cel jest ustalany na poziomie kilku zespołów lub, na przykład w komitecie zarządzania, ale na pewno nie na poziomie tego konkretnego zespołu

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 na drodze do wzmacniania zwinności w organizacji. Skąd się to bierze? Proponujemy Ci kilka praktycznych rozwiązań, które pomogą lepiej wspierać Scrum Masterów, umożliwiając im efektywniejszą pracę. Porządny Agile · Scrum Masterzy samodzielnie nie zmienią Twojej firmy 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 na drodze do wzmacniania zwinności w organizacji. Skąd się to bierze? Proponujemy Ci kilka praktycznych rozwiązań, które pomogą lepiej wspierać Scrum Masterów, umożliwiając im efektywniejszą pracę. Spis treści Definicja problemu Scrum Masterów, od których oczekuje się niemożliwegoDlaczego management może wymagać zbyt wiele od Scrum Masterów? Z czego to może wynikać?Co zarządzający transformacją mogą zrobić, by wesprzeć Scrum Masterów?PodsumowanieFAQ: Scrum Masterzy samodzielnie nie zmienią Twojej firmy📄Transkrypcja podcastu „Scrum Masterzy samodzielnie nie zmienią Twojej firmy„ Definicja problemu Scrum Masterów, od których oczekuje się niemożliwego Co mamy na myśli, gdy definiujemy problem Scrum Masterów, od których oczekuje się niemożliwego? Co się za tym kryje? Obserwując Scrum Masterów, można mieć wrażenie, że odpowiadają oni za całą masę rzeczy, także takich, które wychodzą poza ich podstawowy zakres obowiązków. Spada na ich głowę odpowiedzialność za: motywację zespołu,  jakość techniczną wytwarzanych produktów, pełną koordynację prac w zespole oraz między zespołami, kontrolę nad postępami prac, terminowość działań Zespołu Scrumowego, wdrażanie zwinności w zespole oraz w całej organizacji, często dodatkowo pełnią funkcję lidera zespołu.  To całkiem spora lista odpowiedzialności jak na jedną osobę.  Kiedy mówimy, że Scrum Master nie ma wsparcia, mamy na myśli brak odpowiedniego wsparcia, poparcia i współdziałania od kluczowych ról, takich jak top management, managerowie procesów oraz liderzy zespołów. Brakuje współpracy z osobami odpowiedzialnymi za produkt, takimi jak Product Managerowie czy Product Ownerzy. W wielu firmach Scrum Masterzy nie otrzymują wsparcia nawet od osób odpowiedzialnych za agile’a. Jeśli rola Agile Coach’a lub lidera transformacji agile’a jest oddzielona, może pojawić się rozdźwięk między Scrum Masterami a promotorami zwinności w organizacji. Dodatkowo brak wsparcia ze strony HR-u może prowadzić do licznych konfliktów. Dlaczego management może wymagać zbyt wiele od Scrum Masterów? Z czego to może wynikać? Oto nasza lista hipotez: 1. Zmiana prowadzona jest w sposób powierzchowny Pierwsza hipoteza jest dosyć prosta i łatwa do przewidzenia. Zmiana prowadzona jest w sposób powierzchowny. Organizacja kopiuje pewien wzorzec postępowania, w tym przypadku wzorce związane z frameworkiem scrumowym. Firmy wiedzą, że trzeba powołać stanowisko Scrum Mastera, ale na tym kończy się ich świadomość. Poza zatrudnieniem zawodowych Scrum Masterów, wiele kolejnych kroków, które powinny zostać podjęte, nie jest realizowanych. Brakuje również osób, które mogłyby to skorygować. 2. Przerysowana interpretacja odpowiedzialności Scrum Mastera Firmy, które potrzebują zmiany, mają nadzieję, że Scrum, przyniesie pozytywne rezultaty. Jednak błędnie zakładają, że cała odpowiedzialność spoczywa na Scrum Masterze. Przerysowana jest interpretacja, że tylko Scrum Master odpowiada za wdrażanie i usprawnianie Scruma oraz zwinności w firmie. 3. Oczekiwania idące za nowymi etatami i zarobkami Wysokie oczekiwania względem Scrum Masterów wynikają z kwestii nowych etatów i zarobków. Stanowisko Scrum Mastera często wiąże się z tworzeniem nowych etatów lub reorganizacją, aby te etaty się pojawiły. Te stanowiska są solidnie opłacane w porównaniu do średnich zarobków w organizacji, często na poziomie menedżerskim lub wyższym od specjalistów. W związku z tym może pojawić się uzasadnione oczekiwanie, że skoro Scrum Master jest dobrze wynagradzany, powinien dostarczać wyraźne rezultaty i efekty. Management, decydując się na zatrudnienie Scrum Mastera, buduje inflację oczekiwań, oczekując maksymalnych korzyści z jego funkcjonowania w organizacji. 4. Brak zrozumienia potrzeby wsparcia zmian Management chce rezultatów zwinności, ale często jej nie rozumie i nie inwestuje w zrozumienie. W efekcie nie pojmuje w pełni potrzeby stojącej za zmianami i nie potrafi tych zmian odpowiednio wesprzeć. 5. Priorytetem staje się praca operacyjna W wielu organizacjach, z którymi współpracujemy, część managerów, w tym najwyżsi zarządzający, skupia się głównie na bieżącej działalności, projektach, terminach oraz końcach miesiąca, kwartału czy roku. Mniej uwagi poświęcają rzeczom strategicznym, długofalowym oraz doskonaleniu procesów, sposobu funkcjonowania zespołów czy transformacji zwinnej. Jak już wspominaliśmy, transformacja zwinna jest niekończącym się procesem, który nie da się ukończyć w parę miesięcy czy kwartałów. W sytuacji, gdy cała organizacja jest skupiona na bieżącej pracy operacyjnej, Scrum Masterzy są osamotnieni, ponieważ nikt inny nie zwraca uwagi na dojrzałość zespołów i inne kluczowe aspekty. W efekcie praca długofalowa nie jest powszechna w organizacji. 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. Co zarządzający transformacją mogą zrobić, by wesprzeć Scrum Masterów? Co zatem zarządzający transformacjami mogą zrobić, by wesprzeć Scrum Masterów? W tytule rozdziału bardzo świadomie podkreślamy, do kogo kierujemy te porady. Jeśli jesteś liderem transformacji, sojusznikiem zmiany lub sponsorem zmiany w swojej organizacji, to te punkty są dokładnie dla Ciebie. Jeśli współpracujesz z taką osobą, może to jest lista porad lub sugestii, które warto jej przekazać. Może cały artykuł warto zarekomendować. Co mamy jako pierwsze rozwiązanie na naszej liście? 1. Wypracuj potrzebę zmiany i jej nieuchronność Niezależnie od modelu zmiany, zawsze pojawia się pytanie, dlaczego powinniśmy się zmieniać? Ważne jest, aby ludzie zrozumieli, dlaczego powinniśmy robić rzeczy inaczej niż dotychczas. Pomóż im zrozumieć, że zmiana jest poważna i nie jest to kolejny trend rynkowy, ale rzeczywista potrzeba, dyktowana wewnętrznie lub zewnętrznie. Wymagaj, aby osoby zaangażowane w zmianę znalazły sposób na jej realizację. Odpowiedzi takie jak „Nie da się”, „tak zawsze robiliśmy” czy „tego nie można zrobić w naszej branży” nie powinny być akceptowane. Dlaczego ta porada znalazła się pierwszym miejscu? Zbyt często spotykamy w organizacjach osoby, które wiedzą lub czują, że wystarczy przeczekać zmianę albo mocno zaargumentować, że nic się nie da zrobić, że zawsze działaliśmy w ten sposób i tak będzie dalej. Osoby chcące wprowadzić zmiany, zwłaszcza na poziomie oddolnym, często bez władzy w organizacji, jak Scrum Masterzy, mają trudności w przekonywaniu innych, np. działów prawnych czy osób odpowiedzialnych za compliance i bezpieczeństwo, które niechętnie reagują na zmiany.W każdej firmie są takie osoby, choć nie chcemy nikogo stygmatyzować, dobrze byłoby, gdyby cała organizacja, włącznie z osobami mającymi konkretne obszary odpowiedzialności, ustawiła się w trybie „spróbujmy coś zrobić”, aby dopasować się do ducha zmiany, który jest powszechny i współdzielony przez wszystkich. 2. Zaangażuj w zmianę osoby z obszarów firmy, które podlegają zmianie To nadbudowuje poprzednią myśl, ale chcemy mocno zaakcentować, że w niektórych organizacjach zmiana jest prowadzona i zdefiniowana zbyt wąsko od samego początku. Na przykład transformacja zwinna dotyczy tylko wytwarzania oprogramowania, ale już zespoły wspierające czy odpowiedzialne za pewne procesy uważają, że są poza tą zmianą. Czasem nawet jest to jasno zdefiniowane, że transformacja odbywa się bez udziału biznesu lub pewnych obszarów. Może to być sensownym pierwszym krokiem, jeśli nie ma innej możliwości lub aktualna sytuacja na to nie pozwala. Jednak docelowo warto zdawać sobie sprawę, do jakich konsekwencji takie podejście prowadzi. Możemy mówić o lokalnych optymalizacjach, które czasami są postrzegane jako małe sukcesy. Jednak gdy spojrzymy na szerszy obraz, okazuje się, że drobne zmiany mogą nie mieć większego znaczenia, ponieważ wąskie gardła i nieefektywności mogą być schowane w innych częściach procesu. 3. Postaw cele wspierające zmianę Istotne jest, aby cele wypływały z potrzeby zmiany, były kaskadowo przeniesione na adekwatne poziomy w strukturze organizacji. Przykładem może być sytuacja, w której wszyscy uczestniczący w zmianie mogą mieć wspólny wysokopoziomowy cel, na przykład skrócenie „time to market”, lub cele zdefiniowane na poszczególne obszary. Z perspektywy działu zamówień może to być kontraktowanie się z uwzględnieniem realiów pracy zwinnej. Z perspektywy działu wdrożeń może to być skrócenie cyklu release’ów, a z perspektywy działu jakości – automatyzacja testów. Ta porada jest odpowiedzią na problem różnych priorytetów w różnych częściach organizacji. Jeśli cele są rozbieżne i nie wspierają zmiany, transformacja nie będzie poważnie traktowana i odpowiednio wspierana. Kiedy organizacja chce i potrzebuje się zmienić, wspólne cele dla wszystkich uczestników powinny wspierać te zmiany. Współpraca jest kluczowa, ponieważ żadna osoba solo, ani Scrum Master, ani pojedynczy manager, ani członek zarządu nie osiągnie transformacyjnych celów bez wsparcia średniego i niższego szczebla managementu. 4. Zadbaj o edukację wszystkich zaangażowanych w zmianę To, na co chcemy jeszcze zwrócić uwagę to bycie ostrożnym wobec komunikatów typu „Ta zmiana mnie nie dotyczy” lub „Nie dotyczy mnie w takim stopniu„. Ważne jest, aby wszyscy w organizacji mówili jednym językiem, grali do jednej bramki, rozumieli te same pojęcia i p

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 to może wynikać? Poznaj dziewięć sposobów na to, żeby wzmacniać kompetencje zwinne w zespołach. Porządny Agile · Wzmacnianie kompetencji zwinnych w zespołach Jakie są zagrożenia braku dalszej nauki w praktykach zwinnych? 1. Rozbudowa zespołu o osoby bez zwinnego doświadczenia Bazując na naszych doświadczeniach, mamy dla ciebie kilka przykładów sytuacji, co się zadzieje, jeśli organizacja zaniecha rozwijania kompetencji w zespołach.  Pierwszy z nich dotyczy szybkiego wzrostu liczebności zespołu, z kilku do kilkunastu osób bez uwzględnienia ich doświadczenia w procesie rekrutacji. W konsekwencji nowi pracownicy zdobyli swoje doświadczenie poprzez obserwację kolegów, wykorzystujących konkretne praktyki na co dzień. Finalnie nowym osobom zabrakło zrozumienia w zakresie stosowania praktyk i zasad zwinnych. Osoby te nie do końca rozumiały koncepcji ciągłego usprawniania się, czy codziennych spotkań zespołu.  Spis treści Jakie są zagrożenia braku dalszej nauki w praktykach zwinnych?Przyczyny zatrzymania rozwoju kompetencji zwinnych 9 sposobów wzmacniania kompetencji zwinnych w zespołachFAQ: Wzmacnianie kompetencji zwinnych w zespołach📄Transkrypcja podcastu „Wzmacnianie kompetencji zwinnych w zespołach„ 2. Utrata inicjatorów zwinności Przechodząc do kolejnego przykładu. Grupa pasjonatów wprowadziła w jednej z firm zwinność. Udało im rozpocząć pracę w zespołach, przekonać management do wsparcia zmian, co w efekcie przyniosło pozytywne rezultaty. Z biegiem czasu większość osób, które zainicjowały praktyki zwinne, odeszły z organizacji. Ogień do zmian i rozwoju zgasł pod ich nieobecność, co doprowadziło do marginalizowania zwinności.  Zespoły kontynuowały pracę w iteracjach, cyklicznych spotkaniach, ale bez zrozumienia ich pierwotnego celu. Brak zrozumienia i rutynowe praktyki sprawiły, że zespół przestał rozumieć, dlaczego wprowadzili. Mieli trudności z podejściem do naprawy tego, co stworzyli, a tym, co zrealizowali. 3. Zwalnianie Scrum Masterów Jedna z organizacji zwolniła Scrum Masterów. To był kolejny przypadek. Firma ta miała przeświadczenie, że osiągnęła już wszystko, co wiązało się ze zwinnością. Nic bardziej mylnego. Brak wsparcia Scrum Mastera spowodował, że zabrakło osoby, która dostrzeże, potrzebę rozwoju zespołu, procesu współpracy oraz dostarczania rozwiązań na rynek.  Finalnie lider w zespole skupiał się na technologii, przez co zwinność przestała być priorytetem. Sama praca zespołów budowana na filarach zwinności zaczęła odbiegać od standardów rynkowych, a tym samym przestała wyglądać jak porządny Agile. 4. Skalowanie Scruma Ostatnia historia jest o organizacji, która znalazła się w fazie szybkiego rozwoju/rozrostu. Wdrożyła Scrum poprawnie, na poziomie zespołów uporządkowała chaos, panujący przed wdrożeniem Scruma. Niestety wraz z ogólnym wzrostem napotykała problemy m.in. z rozwojem produktu. Firma zaczęła potrzebować większej skali, aktualnej wiedzy m.in. jak Scrum (dotychczas stosowany był na poziomie zespołów) stał się niewystarczający. W efekcie tego brak pomysłów na wdrożenie nowych narzędzi i technik spowodował stagnację. Brak konkretnego pomysłu wynikał z dawnych doświadczeń, gdy zespół uczył się Scruma. Zespół postrzegał to narzędzie jako sposób na organizację swojej pracy. Słusznie. Jednak na tamtym etapie bardziej ambitne rzeczy pozostawały poza ich zasięgiem. W efekcie zabrakło im wyższego wtajemniczenia i zaawansowania stosowania praktyk zwinnych.  Przyczyny zatrzymania rozwoju kompetencji zwinnych  Poniżej przedstawiamy, kilka głównych hipotez, dla których rozwój kompetencji zwinnych często zatrzymuje się, przestaje być wspierany i rozwijany. Zobacz, jakie mogą z tego wynikać konsekwencje. 1. Przekonanie, że uczymy się tylko raz Firmy często są w przeświadczeniu, że wystarczy tylko jedno szkolenie, które będzie wystarczające na lata. Niezależnie czy jest to Scrum, Kanban, czy  Domain-Driven Design. 2. Transformacja zwinna jako zamknięty projekt Transformacja zwinna traktowana jest jako projekt z początkiem i końcem, a także ograniczonym budżetem. Po zakończeniu projektu brak jest dalszego wsparcia zespołu, inicjacji dalszego jego rozwoju oraz brakiem budżetu na działania z tego zakresu. 3. Niechęć do zwinności Kolejnym przykładem jest zniechęcenie do zwinności jako ogólnej koncepcji, która mogła okazać się zbyt trudna w praktycznym wykorzystaniu. Może również nie spełniać obietnic, które ludzie z nią wiązali. W związku z tym jest przekonanie, że to, co mamy i używamy, jest na tyle istotne, że chcemy to zachować. 4. Wysoki koszt szkoleń Konkretnym powodem, który może hamować dalszy rozwój, stanowi koszt szkoleń. Szczególnie jeśli rozwój oznacza większy program szkoleniowy, wymagający angażowania trenerów i odejmujący ludzi od codziennej, projektowej lub rozwojowej pracy. Takie rozbudowane programy edukacyjne mogą być nierealne do wykonania ze względu na wysoki koszt lub brak odpowiednio wysokiego budżetu w danej organizacji. 5. Konkurencja wzmacniania kompetencji z nowymi trendami Organizacje obserwując aktualne trendy na rynku, przenoszą swoje budżety lub chęci rozwoju pracowników na inne obszary. Może więc dojść do sytuacji, w której szkolenia dotyczące zwinności będą konkurować z innymi szkoleniami, na przykład z zakresu sztucznej inteligencji. 6. Inne priorytety w firmie Następną przyczyną zatrzymania rozwoju kompetencji to identyfikacja w firmie obszarów, które wymagają jeszcze większego doskonalenia niż te, związane z kompetencjami zwinnymi. Spotykamy się z różnymi sytuacjami w organizacjach, gdzie, choć zauważamy potrzebę poprawy kompetencji zwinnych, istnieją obszary, które wymagają pilniejszej uwagi z zakresu: obszaru feedbacku, umiejętności twardych programistów, techniki sprzedaży, wzmacniania mocnych stron pracowników Jeśli zestawimy ww. obszary obok siebie, mogą okazać się one ważniejsze niż rozwijanie kompetencji zwinnych. W takich organizacjach niezbędne jest skupienie się na kompetencjach, które znajdują się w jeszcze gorszym stanie wymagającym natychmiastowej poprawy. 7. Brak spójnego podejścia do edukacji Nasza ostatnia hipoteza sugeruje, że w organizacji nie pracuje się systematycznie, nie rozwija kompetencji w ogóle, bądź w spójny konkretny sposób angażując całe zespoły. Brak jest konsekwentnego procesu rozwoju. Często decyzje dotyczące szkoleń podejmowane są na poziomie lidera lub szefa zespołu, brakuje jednak spójnego i kompleksowego podejścia. Przypominamy, że jeżeli chcesz pogłębić wiedzę jeszcze bardziej, niż robimy to w podcaście, to znajdziesz nasze płatne sklepy na stronie porzadnyagile.pl/sklep 9 sposobów wzmacniania kompetencji zwinnych w zespołach Rozwój kompetencji zwinnych wymaga ciągłego wsparcia i odpowiednich działań. Poniżej dajemy ci kilka konkretnych propozycji, które mogą pomóc w utrzymaniu i rozwijaniu zwinności w zespołach.   1. Zastanów się, jak obecny sposób działania zespołów odpowiada na potrzeby organizacji Zadaj sobie pytanie, w jaki sposób obecny sposób pracy zespołów odpowiada na potrzeby twojej organizacji? Nie istnieją uniwersalne rozwiązania ani metody pracy, które zawsze działają dla każdego zespołu, jednak to, do czego cię zachęcamy to przyjrzenie się: gdzie znajdują się mocne strony zespołu,  w jaki sposób zespół pracuje,  gdzie znajdują się obszary do poprawy w zespole bądź w organizacji.  Dlaczego taki kierunek? Podczas naszych rozmów z managerami organizacji często pojawiają się stwierdzenia, że zespoły nie dostarczają szybko. Napotykają trudności w pracy nad strategicznymi projektami, zadania są trudniejsze niż poprzednie.  Z drugiej strony, mimo posiadania zwinnych lub Scrumowych zespołów, zdarza się, że zespoły nie radzą sobie z mechanizmami zwinnymi. Co sugeruje, że kompetencje zwinne wymagają ulepszenia. Warto zastanowić się nad potrzebami organizacji i sprawdzić, czy obecne zespoły, które masz, spełniają te oczekiwania. Jeśli nie, być może konieczne będzie głębsze przemyślenie sytuacji nie tylko na poziomie zespołu, ale i całej organizacji.  2. Diagnozuj wewnętrzny stan wiedzy To, co proponujemy dla ciebie w kolejnym punkcie to diagnoza wewnętrznego stanu wiedzy wraz z przygotowanymi do nich adekwatnymi rozwiązaniami. Jeśli widzimy, że potrzebą organizacji są lepiej funkcjonujące lub współpracujące zespoły na większą skalę, warto zastanowić się, jakie kompetencje obecnie posiadają te zespoły.  Bardzo dokładnie należy ocenić jednakowo:   umiejętności profesjonalistów, stopień doświadczenia zespołów,  zdolność zespołów do radzenia sobie z różnymi wyzwaniami,  jakie stosują praktyki.  Niezbędne w tym zakresie jest przeprowadzenie dokładnego i systematycznego przeglądu, oraz analitycznego podejścia do sprawy. Na tej podstawie wyciągniesz wnioski dotyczące potrzeb i braków, które należy uzupełnić konkretnymi rozwiązaniami. 3. Poproś eksperta zewnętrznego o rekomendacje zmian w procesach Częstym rozwiązaniem, po które sięgają firmy, jest zaproszenie osoby z rynku, która ma świeże spojrzenie i doświadczenie z wieloma organizacjami. Potrafi zobaczyć, jak pracuje zespół. Zbiera i dostarcza rekomendacje, obejmujące m.in. szkolenia lub konkretne aspekty związane z rozwojem. Nie wszystko jednak można naprawić za pomocą jednej techniki czy zmiany na poziomie organizacyjnym. Proste rekomendacje, takie jak uzupełnienie wiedzy na temat zwinności w zespołach lub zapewnienie wsparcia dla Product Ownerów, mogą okazać się strzałem w dziesiątkę. Jako realizatorzy rekomendacji, przeprowadzenia diagnozy mamy do ciebie apel, o to, żeby już na początku współpracy z ekspertem jasno ustalić zakres rekomendacji. Tak, aby były one szersze, niż te w ofercie. Dlaczego? Diagnoza nie powinna być pretekstem do sprzedania kilku szkoleń z portfolio eksperta. Warto jasno określić zasady współpracy z ekspert

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 tej rozmowie usłyszysz o ciągłym doskonaleniu procesu i produktu wraz z listą rekomendacji, co można zrobić, żeby uniknąć pułapki zbyt późnych usprawnień. Porządny Agile · Jak uniknąć pułapki Lessons Learned? Lessons Learned, czyli wyciąganie wniosków na końcu projektu, dla wielu wydaje się, być sensownym podejściem. Dowiedz się, dlaczego warto zrewidować tę koncepcję i jak efektywniej usprawniać produkty i procesy. Pomysł na poruszenie tego tematu pojawił się podczas konferencji dotyczącej zbierania wymagań. Jacek opowiadał na niej o tym, dlaczego koncepcja Lessons Learned jest bardziej antywzorcem niż polecaną przez niego praktyką. Wzbudziło to duże zainteresowanie i postanowiliśmy rozwinąć to zagadnienie.  Spis treści Czym jest Lessons Learned?Ciągłe doskonalenie procesuDlaczego warto się usprawniać?Ciągłe doskonalenie produktuPodejście iteracyjno-przyrostoweKorzyści z podejścia iteracyjno-przyrostowegoJak wprowadzić do zespołu podejście ciągłego doskonalenia procesu i ciągłego doskonalenia produktu?FAQ: Jak uniknąć pułapki Lessons Learned?📄Transkrypcja podcastu „Jak uniknąć pułapki Lessons Learned?” Czym jest Lessons Learned? Lessons Learned jest powszechnym narzędziem stosowanym w zarządzaniu projektami. Polega na tym, że bazując na dotychczasowych działaniach, zbiera się i podsumowuje wnioski. Na tej podstawie ustalane są w zespole projektowym potrzebne zmiany, np. w podejściu do pracy zespołu lub do sposobu działania procesów, czy też dostosowania narzędzi dla kolejnych projektów w przyszłości.  Najczęściej polega to na spotkaniu podsumowującym pracę po skończonym projekcie lub wdrożeniu. Cały zespół projektowy zastanawia się przez chwilę, co można było zrobić lepiej. Przemyślenia te i wnioski są spisywane, aby wiedziedzieć jak działać lepiej w przyszłości. Koncepcja Lessons Learned ma rację bytu, w sytuacji, gdy jest to jedyna rzecz, jaką ma zrobić zespół w ramach wyciągania wniosków, czy szukania usprawnień. Pozwala ona, chociaż w małym stopniu unikać ponownych błędów lub zawirowań. Jednocześnie Lessons Learned może być taktyką organizacji, która się uczy, a także w pewnym sensie elementem rozwoju osobistego członków zespołu, z których każdy nabiera coraz lepszych doświadczeń na temat tego, co działa, co nie działa, jak działać lepiej.  Z obserwacji niestety wiemy, że z implementacją tego podejścia bywa różnie, zwłaszcza gdy jest traktowana, tylko jako pewien punkt na liście do odhaczenia, zamiast stanowić szczerą refleksję. Często jest ona też realizowana już po skończonym projekcie, kiedy ludzie są już myślami w nowych zadaniach, zespoły się mieszają lub realizują całkowicie odmienne projekty. Bywa to też traktowane jako smutny obowiązek bez dostrzegania pozytywnych aspektów, które mogą usprawniać działanie w przyszłości.  Jednocześnie widzimy, że jest to po prostu zwykłe dokumentowanie pewnych wniosków i nacisk jest kładziony na to, żeby je dobrze spisać i to jest głównym celem ćwiczenia. Wnioski potem nie są wykorzystywane, a propozycji zmian nikt nie wdraża w życie. Bywa też tak, że ze spisanych przemyśleń korzysta zupełnie inny zespół, więc nie ma tu motywacji, żeby zrobić to rzetelnie. Ciągłe doskonalenie procesu Lessons Learned stoi trochę w kontrze z ciągłym doskonaleniem procesu, gdyż zgodnie z tym, co wspomnieliśmy powyżej, moment refleksji pojawia się trochę późno, bo na koniec projektu. Z kolei podejście ciągłego doskonalenia procesu sugeruje, aby takie ćwiczenie odbywało się częściej, np. co tydzień lub co 2 tygodnie albo po każdej iteracji czy innym rodzaju cyklu.   Koncepcja ciągłego doskonalenia podczas korzystania ze Scruma zwykle łączona jest z Retrospektywami Sprintu, natomiast my chcemy Cię zachęcić do podejścia, jakie znamy od Alistair’a Cockburn’a, czyli do nano-usprawnień. Są to takie, naprawdę drobne usprawnia, dzięki którym ciągle się doskonalimy, ciągle poprawiamy swój proces pracy i  sposób działania zespołu, usprawniamy przebieg spotkań, szukamy lepszych narzędzi czy taktyk. Stawiamy sobie tu proste pytanie: co działa, co warto wypróbować, a potem robimy małe kroki i przeprowadzamy drobne eksperymenty. Można to robić np. na koniec Daily, gdzie zespół odpowiada na pytania: jak bardzo wartościowe było to spotkanie, co działa dobrze, a co można by zrobić lepiej. Wystarczy dosłownie 5 minut rozmowy każdego dnia, gdyż to już po tygodniu może doprowadzić, że Daily stanie się satysfakcjonujące i przydatne dla wszystkich.  Nano-usprawnienia sprawdzą się w zasadzie przy każdej czynności, czy to w przypadku pojedynczego warsztatu z klientem, sesji planowania, czy Refinementu Backlogu Produktu. Nie ma tu potrzeby przeprowadzania jakiejś formy rozgrzewki, głosowania kropkami, czy długiej burzy mózgów. Wystarczy szybka rozmowa w zespole i wspólne zastanowienie się, czy jest coś, co można przetestować, zrobić inaczej, poprawić. Dlaczego warto się usprawniać? Podzielimy się 5 najważniejszymi naszym zdaniem powodami, dla których warto się nieustannie usprawniać. Uniknięcie popełniania tych samych błędów. Zespoły, z którymi rozmawiamy często narzekają, na popełnianie wciąż tych samych błędów, co jest bardzo frustrujące. Ciągłe usprawnianie procesu pomaga zidentyfikować te błędy, a następnie w prosty sposób je wyeliminować. Uniknięcie popełniania tych samych błędów. Zespoły, z którymi rozmawiamy często narzekają, na popełnianie wciąż tych samych błędów, co jest bardzo frustrujące. Ciągłe usprawnianie procesu pomaga zidentyfikować te błędy, a następnie w prosty sposób je wyeliminować. Poszukiwanie innowacyjnych sposobów wykonywania pracy. Wykonywanie pracy wciąż w ten sam sposób powoduje pewien rodzaj stagnacji, brak rozwoju zarówno całego zespołu, jak i poszczególnych jego członków. Do pracy wkrada się rutyna, którą można zastąpić ciekawością wzbudzoną przez eksperymenty wprowadzane do sposobu pracy. Można spróbować nowego podejścia, innej taktyki, prowadzenia spotkań czy sposoby planowania pracy.  Pozostawanie konkurencyjnym na rynku i ciągłe dążenie do doskonałości.Konkurencja nie śpi i należy o tym pamiętać. W czasie, gdy my pozostajemy w znanej nam strefie komfortu i nic nie zmieniamy, to firma, która zabiega o tego samego klienta, szuka usprawnień każdego tygodnia i w ciągu roku robi to aż 52 razy. To nie tylko prowadzi do podniesienia efektywności pracy, ale i zwiększa zaangażowanie zespołu, który widzi, że może się cały czas rozwijać. Uzyskiwanie tego samego efektu mniejszym kosztem.Szukając ciągłych usprawnień, dbamy o wydajność procesu, sprawniejsze wykonywanie zadań, a blokady są eliminowane. Często przynosi to namacalne efekty finansowe, chociażby pośrednio poprzez wygodniejsze i szybsze działanie. Poprawa motywacji zespołu.Wspomnieliśmy już o tym wcześniej, jednak chcemy podkreślić to jeszcze raz. Usunięcie blokad, utrudnień w pracy, elementów, które powodują frustrację, pozytywnie wpływa na motywację zespołu. Mniej jest stresu, nieprzewidywalności i zniechęcenia. Wielokrotnie obserwowaliśmy, jak zmienia się energia w zespole, gdy jego członkowie widzą, że mają realny wpływ na swoją pracę i widzą, że ich usprawnienia przynoszą efekty. Więcej o tym, dlaczego się usprawniać, co może podlegać usprawnieniom i jak przeprowadzać sesje usprawnieniowe mówimy w naszym webinarze Porządna Retrospektywa Sprintu Ciągłe doskonalenie produktu Podobnie jak Lessons Learned są antywzorcem w przypadku wykonywania tego ćwiczenia na koniec projektu, to samo możemy powiedzieć o praktykowaniu tego na poziomie zarządzania rozwojem produktu.  Bardzo często obserwujemy wyciąganie wniosków i wprowadzanie poprawek dopiero po weryfikacji rynkowej. Nie ma już okazji, aby szybko coś poprawić w ramach bieżącej inicjatywy, a wnioski, które się pojawią, zazwyczaj mało kogo już interesują. Refleksja na temat produktu dopiero w momencie, kiedy ten produkt wydajemy czy pokazujemy światu, ma kilka zasadniczych wad: Moment weryfikacji założeń biznesowych pojawia się naprawdę bardzo późno w procesie. Założenia te mogą już zostać na stałe, jeśli nie ma w planach robienia kolejnej rundy usprawnień lub modyfikacji produktu. Zatem wszystkie błędne decyzje zostaną na rynku, a im dłużej czekamy, tym ewentualne ich skorygowanie staje się coraz kosztowniejsze.  Poprawienie czegokolwiek w wielu organizacjach wymaga zgłoszenia nowego projektu. Wynika to z różnego rodzaju procedur lub ograniczeń formalnych czy narzędziowych, funkcjonujących w danej firmie. Prowadzi to do sytuacji, w której poprawienie czegokolwiek jest po prostu prawie niemożliwe, albo wymaga bardzo dużych wysiłków, albo te poprawki są zrobione minimalnym możliwym kosztem i byle jak. Pojawia się ryzyko idealistycznego dążenia do wypuszczenia perfekcyjnego produktu, co jest wynikiem świadomości, że nie będzie możliwości późniejszych uprawnień. Blokuje to kreatywność, a dodatkowo może spowodować paraliż analityczny i wydłużenie procesu decyzyjnego.  Podejście iteracyjno-przyrostowe W celu zminimalizowania opisanych przez nas problemów proponujemy podejście iteracyjno-przyrostowe, z wczesnym wdrożeniem pierwszej wersji i częstymi kolejnymi wdrożeniami rozwijającymi produkt. Dzięki takiemu działaniu produkt rozwija się małymi krokami, począwszy od zaspokojenia takich podstawowych potrzeb klienta, a może nawet potrzeb tylko pewnej podgrupy klientów. Produkt już na wczesnych etapach trafia do odbiorcy docelowego, przez co jest okazja, aby zebrać informację zwrotną i wyłapać ewentualne błędne założenia. W podejściu tym masz możliwość wprowadzania poprawek w przyszłości, zmniejszasz też presję na to, aby od razu stworzyć idealne rozwiązanie. Korzyści z podejścia iteracyjno-przyrostowego Otrzymasz wcześniejszy feedback i udoskonalisz rozwiązanie. Wcześniej dostarczysz część wartości na rynek, klienci będą mogli poznać p