Advertise on podcast: 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,

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

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

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.

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

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 w

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

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. Prz

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 dz

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ół potrzeb

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

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 jed

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 najw

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ś

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 dekla