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ć okaz

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

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 mana

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ą

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ść. Tak

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ą

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

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łniejsz

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 z

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ł

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,

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

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

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 o

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 Mast

Poznaj narzędzie Circle of influence, które pomaga zespołom zwinnym zidentyfikować, na co mają pełny, częściowy lub żaden wpływ. Dzięki temu zespoły mogą skupić się na obszarach, które są w ich zasięgu, co prowadzi do efektywniejszych usprawnień i zwiększenia satysfakcji z pracy. Dowiesz się też jakie zastosowanie ma Circle of influence w Retrospektywie oraz innych kontekstach, takich jak zarządzanie zależnościami czy planowanie zmian w organizacji. Porządny Agile · Circle Of Influence Ostatnio podczas warsztatów przeprowadziliśmy dyskusję z pewnym zespołem, który był przekonany, że nie ma już niczego, co można usprawnić. Po głębszym zbadaniu tematu doszliśmy do wspólnego wniosku, że istnieją obszary do poprawy, ale nie leżą one w zasięgu mocy sprawczej zespołu. Próby rozmowy o tych kwestiach były frustrujące, więc zespół postanowił całkowicie zrezygnować z Retrospektyw. Spis treści Czym jest Circle of influence?Jakie problemy rozwiązuje Circle of influence?Jak z tego skorzystać?Do jakich działań można użyć Circle of influence?FAQ: Circle of influence📄Transkrypcja podcastu „Circle of influence” Ten przypadek był pojedynczym wydarzeniem z warsztatu, ale jest znamienny, takie sytuacje spotykamy częściej. Kiedy zespół ma poczucie, że nic nie da się poprawić, zwłaszcza w obszarach poza jego kontrolą, jednym z rozwiązań, które najczęściej proponujemy, jest narzędzie zwane Circle of influence. Czym jest Circle of influence? Koncept Circle of influence został stworzony przez psychologa Kurta Lewina, a później spopularyzowany i nieco zmodyfikowany przez Stephena Coveya, autora znanych koncepcji związanych z nawykami efektywnego działania. Będziemy używać terminu „Circle of influence” jako nazwy narzędzia, mimo że istnieje polskie tłumaczenie „krąg wpływu.” Trzymamy się angielskiej nazwy, ponieważ w biznesowym obiegu jest ona częściej używana, a polskie tłumaczenia, zwłaszcza w szczegółach, nie zawsze oddają dokładnie niuanse tej koncepcji. Czym dokładnie jest ta koncepcja? Zakłada ona, że istnieją trzy poziomy naszego wpływu:  nie mamy żadnego wpływu. pełny wpływ, częściowy wpływ, W psychologicznych korzeniach tej koncepcji mocno wybrzmiewa założenie, że niektóre osoby poświęcają zbyt dużo uwagi na rzeczy, na które nie mają wpływu. To powoduje stres, blokuje działanie, wywołuje poczucie bezsilności i brak satysfakcji. Psychologiczny aspekt tej koncepcji ma na celu przekierowanie uwagi na rzeczy, na które faktycznie mamy wpływ, i skupienie się na nich, zamiast na tych, które są poza naszą kontrolą. W zespołach zwinnych stosujemy to narzędzie, aby pobudzić refleksję nad możliwymi zmianami oraz nad tym, jaki wpływ zespół ma na swoje otoczenie. Wracając do historii z początku, są zespoły, które koncentrują się na dużych niedoskonałościach znajdujących się poza ich strefą wpływu i skupiają się na tym, że nie mogą tych elementów zmienić. Jednocześnie zaniedbują obszary, na które mają wpływ, zarówno bezpośredni, jak i pośredni, i gdzie faktycznie mogliby dokonać zmian. Obejrzyj nagranie rozmowy Jakie problemy rozwiązuje Circle of influence? Przytoczymy ci po jednym, celowo różnym, przykładzie, aby pokazać, gdzie zastosowalibyśmy Circle of influence w konkretnych sytuacjach biznesowych. Pierwszym przykładem jest praca z grupą liderów, którzy starali się poprawić współpracę między sobą, aby skuteczniej i bardziej skoordynowanie przeprowadzić zmianę w organizacji. Zapytani o ostatnie usprawnienia, które zrealizowali, przedstawili różne tłumaczenia, że „nie da się”, „jest szklany sufit”, „próbowaliśmy wielokrotnie”, „odbijaliśmy się od organizacji” i generalnie nie ma poprawy. Wprowadzenie Circle of fnfluence pokazało, że tematy, które próbowali rozwiązywać, były poza ich strefą wpływu. Rekomendacja dla tego zespołu liderów polegała na tym, aby skupili się na rzeczach, na które mają częściowy, a zwłaszcza pełny wpływ i skierowali tam całą swoją energię. Zastanowili się się, jak organizują się jako liderzy, jak pracują z zespołami i jak wspierają procesy w organizacji. W wymienionych obszarach mieli możliwość wprowadzenia realnych zmian, bo  właśnie tam mieli pełny lub częściowy wpływ. Kolejna historia wykorzystania Circle of influence wiąże się z pomocą pewnemu zespołowi, który pracował Scrumem od dłuższego czasu i był w tym naprawdę dobry. Zespół osiągał świetne wyniki, miał poczucie, że wiele poprawił, dobrze współpracował i kończył zadania, których się podejmował. Wiedzieli, że są już bardzo mocnym zespołem, jednak potrzebowali wsparcia, ponieważ zaczęło brakować im pomysłów na dalsze usprawnienia. Kiedy zagłębiliśmy się w temat, okazało się, że zespół łatwo wyliczał rzeczy, które można by zmienić, ale były to głównie zmiany o dużym kalibrze – organizacyjne, procesowe, dotyczące całej firmy. Byli na tyle zaawansowani, że widzieli potrzebę zmian na poziomie całej organizacji, choć w tej firmie jeszcze nie było na to gotowości. To prowadziło do pewnego marazmu w zespole – czuli

Poprawnie skonstruowany Cel Sprintu to wyzwanie dla niejednego zespołu. Widzimy to dosyć często w naszej codziennej pracy. Z czego może wynikać ten problem? Zdradzamy kilkanaście naszych hipotez. Mamy też dla Ciebie kilka rozwiązań, które pomogą poprawnie skonstruować Cel Sprintu. Porządny Agile · Dlaczego tak trudno ustalić Cel Sprintu? Cel Sprintu jest zobowiązaniem będącym częścią Backlogu Sprintu. Jest on ustalany przez Zespół Scrumowy podczas planowania Sprintu. Określa, co zespół chce osiągnąć w ramach Sprintu. Dobrze sformułowany Cel daje developerom pewną swobodę w doborze rozwiązania w trakcie Sprintu. Cel Sprintu pozostaje niezmienny przez cały Sprint, co zapewnia zespołowi skupienie, spójność współpracy i stały punkt odniesienia przez cały czas trwania Sprintu. Spis treści Powody problemów w konstruowaniu celu SprintuJak rozwiązać problemy w zbudowaniu celu Sprintu? FAQ: Dlaczego tak trudno ustalić Cel Sprintu?📄Transkrypcja podcastu „Dlaczego tak trudno ustalić Cel Sprintu?„ Powody problemów w konstruowaniu celu Sprintu 1. Brak zrozumienia czym jest Cel Sprintu To bardzo podstawowy, ale istotny problem. Obserwujemy, że brak dobrego zrozumienia, dlaczego Cel Sprintu jest obecny w Scrumie, prowadzi do problemów z jego praktycznym wykorzystaniem podczas Sprintu. Cel Sprintu jest narzędziem, które pozwala nam osiągnąć skupienie. Z natłoku różnych tematów, którymi moglibyśmy się zająć w trakcie Sprintu, wybieramy jeden określony kawałek – coś, co chcemy osiągnąć na koniec Sprintu, czy to funkcjonalnie, czy biznesowo. Cel Sprintu powinien być dla nas najistotniejszy i pomagać w podejmowaniu codziennych decyzji podczas pracy w Sprincie. 2. Założenie, że Cel dotyczy całego zakresu i wszystkich Developerów Mamy tutaj do czynienia z nadinterpretacją teorii, która mówi, że cel zapewnia skupienie i pozwala na współpracę. Choć to prawda, przesadne zrozumienie tego może prowadzić do myślenia, że Cel Sprintu musi pokryć 100% elementów wziętych do Sprintu, włącznie z tymi, które są nieco inne niż główne zadanie.  Podobnie problem może dotyczyć developerów. Jeśli zespół składa się z sześciu developerów, pięciu może realizować główne zadanie, ale szósty może zajmować się np. zadaniami utrzymaniowymi. W takich przypadkach zespoły próbują na siłę włączyć wszystkie zadania i wszystkich developerów do Celu Sprintu, co prowadzi do tworzenia celów zbyt ogólnych lub wieloelementowych. Naszym zdaniem jest to antywzorzec. Odwracając ten problem, Cel Sprintu nie musi pokrywać całego zakresu i nie musi dotyczyć każdego developera w danym momencie. Ważne jest, aby zrozumieć specyfikę danego zespołu i skupić się na głównym celu, który jest najistotniejszy dla Sprintu. 3. Poczucie, że jeśli coś nie jest w Celu Sprintu, to nie jest ważne Wyobraź sobie sytuację, w której zespół konstruuje Cel Sprintu i pewne prognozowane elementy z Backlogu Produktu wchodzą w jego zakres. Nagle ktoś mówi, że naprawa jakiegoś błędu jest również ważna, ale skoro nie ma jej w Celu Sprintu, to zespół nie będzie się na niej skupiać. Cel Sprintu ma wskazywać drogę, być drogowskazem, latarnią morską dla zespołu, ale to nie oznacza, że rzeczy spoza Celu Sprintu są kompletnie nieważne i można je zignorować. W praktyce może się zdarzyć, że rzeczy poza Celem Sprintu, gdy w trakcie Sprintu odkryje się problemy, mogą stać się kandydatami do renegocjacji. Jednak na etapie planowania Sprintu nie powinniśmy od razu zakładać, że czegoś nie zrobimy tylko dlatego, że nie jest w Celu Sprintu. 4. Realizacja Celów jest rozliczana przez management  Realizacja Celu Sprintu jest rozliczana przez management, co może być źródłem problemów. Dlaczego? Ponieważ zespoły zaczynają podejmować niewskazane negocjacje.  Jeśli zespoły są ściśle monitorowane i kontrolowane, ustalają taki Cel Sprintu, aby jak najszybciej go zaliczyć. Niestety, widzieliśmy na własne oczy, że jako Cel Sprintu formułowane jest coś, co można zrealizować w 1-2 dni. Oczywiście, zespół wykonuje wiele innych zadań, ale ma potencjał, aby wyznaczyć bardziej ambitny Cel Sprintu. Jednak zespoły są zachęcane przez management do tego, aby zawsze mieć wszystko „na zielono”. W rezultacie cel jest albo banalny, albo tak negocjowany, żeby go zawsze zaliczyć. To powoduje, że Cel Sprintu nie spełnia swojej podstawowej funkcji, a staje się narzędziem do unikania problemów i zapewnienia, że wszystko wygląda dobrze w raportach. Takie podejście jest zrozumiałe w korporacyjnym świecie, ale może być bardzo frustrujące dla Product Ownerów, którzy chcieliby stawiać bardziej ambitne cele. Ponadto, koncepcja pracy eksperymentalnej i przyrostowej całkowicie się rozmywa, ponieważ zespół skupia się na bezpieczeństwie i zaliczaniu celów, zamiast na faktycznym rozwoju i dostarczaniu wartości. 5. Brak pracy przyrostowej Dlaczego tak trudno ustawić sensowny Cel Sprintu? Jednym z głównych powodów jest brak pracy przyrostowej. Mówimy o sytuacji, w której zespół realizuje z góry założony za

Scrum Masterzy coraz częściej mierzą się z ogromną odpowiedzialnością, ale brakuje im adekwatnego wsparcia. Nierealistyczne oczekiwania stanowią dla nich wyzwanie, a jednocześnie są dużym problemem na drodze do wzmacniania zwinności w organizacji. Skąd się to bierze? Proponujemy Ci kilka praktycznych rozwiązań, które pomogą lepiej wspierać Scrum Masterów, umożliwiając im efektywniejszą pracę. Porządny Agile · Scrum Masterzy samodzielnie nie zmienią Twojej firmy Scrum Masterzy coraz częściej mierzą się z ogromną odpowiedzialnością, ale brakuje im adekwatnego wsparcia. Nierealistyczne oczekiwania stanowią dla nich wyzwanie, a jednocześnie są dużym problemem na drodze do wzmacniania zwinności w organizacji. Skąd się to bierze? Proponujemy Ci kilka praktycznych rozwiązań, które pomogą lepiej wspierać Scrum Masterów, umożliwiając im efektywniejszą pracę. Spis treści Definicja problemu Scrum Masterów, od których oczekuje się niemożliwegoDlaczego management może wymagać zbyt wiele od Scrum Masterów? Z czego to może wynikać?Co zarządzający transformacją mogą zrobić, by wesprzeć Scrum Masterów?PodsumowanieFAQ: Scrum Masterzy samodzielnie nie zmienią Twojej firmy📄Transkrypcja podcastu „Scrum Masterzy samodzielnie nie zmienią Twojej firmy„ Definicja problemu Scrum Masterów, od których oczekuje się niemożliwego Co mamy na myśli, gdy definiujemy problem Scrum Masterów, od których oczekuje się niemożliwego? Co się za tym kryje? Obserwując Scrum Masterów, można mieć wrażenie, że odpowiadają oni za całą masę rzeczy, także takich, które wychodzą poza ich podstawowy zakres obowiązków. Spada na ich głowę odpowiedzialność za: motywację zespołu,  jakość techniczną wytwarzanych produktów, pełną koordynację prac w zespole oraz między zespołami, kontrolę nad postępami prac, terminowość działań Zespołu Scrumowego, wdrażanie zwinności w zespole oraz w całej organizacji, często dodatkowo pełnią funkcję lidera zespołu.  To całkiem spora lista odpowiedzialności jak na jedną osobę.  Kiedy mówimy, że Scrum Master nie ma wsparcia, mamy na myśli brak odpowiedniego wsparcia, poparcia i współdziałania od kluczowych ról, takich jak top management, managerowie procesów oraz liderzy zespołów. Brakuje współpracy z osobami odpowiedzialnymi za produkt, takimi jak Product Managerowie czy Product Ownerzy. W wielu firmach Scrum Masterzy nie otrzymują wsparcia nawet od osób odpowiedzialnych za agile’a. Jeśli rola Agile Coach’a lub lidera transformacji agile’a jest oddzielona, może pojawić się rozdźwięk między Scrum Masterami a promotorami zwinności w organizacji. Dodatkowo brak wsparcia ze strony HR-u może prowadzić do licznych konfliktów. Dlaczego management może wymagać zbyt wiele od Scrum Masterów? Z czego to może wynikać? Oto nasza lista hipotez: 1. Zmiana prowadzona jest w sposób powierzchowny Pierwsza hipoteza jest dosyć prosta i łatwa do przewidzenia. Zmiana prowadzona jest w sposób powierzchowny. Organizacja kopiuje pewien wzorzec postępowania, w tym przypadku wzorce związane z frameworkiem scrumowym. Firmy wiedzą, że trzeba powołać stanowisko Scrum Mastera, ale na tym kończy się ich świadomość. Poza zatrudnieniem zawodowych Scrum Masterów, wiele kolejnych kroków, które powinny zostać podjęte, nie jest realizowanych. Brakuje również osób, które mogłyby to skorygować. 2. Przerysowana interpretacja odpowiedzialności Scrum Mastera Firmy, które potrzebują zmiany, mają nadzieję, że Scrum, przyniesie pozytywne rezultaty. Jednak błędnie zakładają, że cała odpowiedzialność spoczywa na Scrum Masterze. Przerysowana jest interpretacja, że tylko Scrum Master odpowiada za wdrażanie i usprawnianie Scruma oraz zwinności w firmie. 3. Oczekiwania idące za nowymi etatami i zarobkami Wysokie oczekiwania względem Scrum Masterów wynikają z kwestii nowych etatów i zarobków. Stanowisko Scrum Mastera często wiąże się z tworzeniem nowych etatów lub reorganizacją, aby te etaty się pojawiły. Te stanowiska są solidnie opłacane w porównaniu do średnich zarobków w organizacji, często na poziomie menedżerskim lub wyższym od specjalistów. W związku z tym może pojawić się uzasadnione oczekiwanie, że skoro Scrum Master jest dobrze wynagradzany, powinien dostarczać wyraźne rezultaty i efekty. Management, decydując się na zatrudnienie Scrum Mastera, buduje inflację oczekiwań, oczekując maksymalnych korzyści z jego funkcjonowania w organizacji. 4. Brak zrozumienia potrzeby wsparcia zmian Management chce rezultatów zwinności, ale często jej nie rozumie i nie inwestuje w zrozumienie. W efekcie nie pojmuje w pełni potrzeby stojącej za zmianami i nie potrafi tych zmian odpowiednio wesprzeć. 5. Priorytetem staje się praca operacyjna W wielu organizacjach, z którymi współpracujemy, część managerów, w tym najwyżsi zarządzający, skupia się głównie na bieżącej działalności, projektach, terminach oraz końcach miesiąca, kwartału czy roku. Mniej uwagi poświęcają rzeczom strategicznym, długofalowym oraz doskonaleniu procesów, sposobu funkcjonowania zesp

Obserwujemy, że w niektórych firmach kompetencje zwinne rozwijane są tylko na początku transformacji zwinnej. Potem zwinność i kompetencje z nią związane powoli zanikają. Z czego to może wynikać? Poznaj dziewięć sposobów na to, żeby wzmacniać kompetencje zwinne w zespołach. Porządny Agile · Wzmacnianie kompetencji zwinnych w zespołach Jakie są zagrożenia braku dalszej nauki w praktykach zwinnych? 1. Rozbudowa zespołu o osoby bez zwinnego doświadczenia Bazując na naszych doświadczeniach, mamy dla ciebie kilka przykładów sytuacji, co się zadzieje, jeśli organizacja zaniecha rozwijania kompetencji w zespołach.  Pierwszy z nich dotyczy szybkiego wzrostu liczebności zespołu, z kilku do kilkunastu osób bez uwzględnienia ich doświadczenia w procesie rekrutacji. W konsekwencji nowi pracownicy zdobyli swoje doświadczenie poprzez obserwację kolegów, wykorzystujących konkretne praktyki na co dzień. Finalnie nowym osobom zabrakło zrozumienia w zakresie stosowania praktyk i zasad zwinnych. Osoby te nie do końca rozumiały koncepcji ciągłego usprawniania się, czy codziennych spotkań zespołu.  Spis treści Jakie są zagrożenia braku dalszej nauki w praktykach zwinnych?Przyczyny zatrzymania rozwoju kompetencji zwinnych 9 sposobów wzmacniania kompetencji zwinnych w zespołachFAQ: Wzmacnianie kompetencji zwinnych w zespołach📄Transkrypcja podcastu „Wzmacnianie kompetencji zwinnych w zespołach„ 2. Utrata inicjatorów zwinności Przechodząc do kolejnego przykładu. Grupa pasjonatów wprowadziła w jednej z firm zwinność. Udało im rozpocząć pracę w zespołach, przekonać management do wsparcia zmian, co w efekcie przyniosło pozytywne rezultaty. Z biegiem czasu większość osób, które zainicjowały praktyki zwinne, odeszły z organizacji. Ogień do zmian i rozwoju zgasł pod ich nieobecność, co doprowadziło do marginalizowania zwinności.  Zespoły kontynuowały pracę w iteracjach, cyklicznych spotkaniach, ale bez zrozumienia ich pierwotnego celu. Brak zrozumienia i rutynowe praktyki sprawiły, że zespół przestał rozumieć, dlaczego wprowadzili. Mieli trudności z podejściem do naprawy tego, co stworzyli, a tym, co zrealizowali. 3. Zwalnianie Scrum Masterów Jedna z organizacji zwolniła Scrum Masterów. To był kolejny przypadek. Firma ta miała przeświadczenie, że osiągnęła już wszystko, co wiązało się ze zwinnością. Nic bardziej mylnego. Brak wsparcia Scrum Mastera spowodował, że zabrakło osoby, która dostrzeże, potrzebę rozwoju zespołu, procesu współpracy oraz dostarczania rozwiązań na rynek.  Finalnie lider w zespole skupiał się na technologii, przez co zwinność przestała być priorytetem. Sama praca zespołów budowana na filarach zwinności zaczęła odbiegać od standardów rynkowych, a tym samym przestała wyglądać jak porządny Agile. 4. Skalowanie Scruma Ostatnia historia jest o organizacji, która znalazła się w fazie szybkiego rozwoju/rozrostu. Wdrożyła Scrum poprawnie, na poziomie zespołów uporządkowała chaos, panujący przed wdrożeniem Scruma. Niestety wraz z ogólnym wzrostem napotykała problemy m.in. z rozwojem produktu. Firma zaczęła potrzebować większej skali, aktualnej wiedzy m.in. jak Scrum (dotychczas stosowany był na poziomie zespołów) stał się niewystarczający. W efekcie tego brak pomysłów na wdrożenie nowych narzędzi i technik spowodował stagnację. Brak konkretnego pomysłu wynikał z dawnych doświadczeń, gdy zespół uczył się Scruma. Zespół postrzegał to narzędzie jako sposób na organizację swojej pracy. Słusznie. Jednak na tamtym etapie bardziej ambitne rzeczy pozostawały poza ich zasięgiem. W efekcie zabrakło im wyższego wtajemniczenia i zaawansowania stosowania praktyk zwinnych.  Przyczyny zatrzymania rozwoju kompetencji zwinnych  Poniżej przedstawiamy, kilka głównych hipotez, dla których rozwój kompetencji zwinnych często zatrzymuje się, przestaje być wspierany i rozwijany. Zobacz, jakie mogą z tego wynikać konsekwencje. 1. Przekonanie, że uczymy się tylko raz Firmy często są w przeświadczeniu, że wystarczy tylko jedno szkolenie, które będzie wystarczające na lata. Niezależnie czy jest to Scrum, Kanban, czy  Domain-Driven Design. 2. Transformacja zwinna jako zamknięty projekt Transformacja zwinna traktowana jest jako projekt z początkiem i końcem, a także ograniczonym budżetem. Po zakończeniu projektu brak jest dalszego wsparcia zespołu, inicjacji dalszego jego rozwoju oraz brakiem budżetu na działania z tego zakresu. 3. Niechęć do zwinności Kolejnym przykładem jest zniechęcenie do zwinności jako ogólnej koncepcji, która mogła okazać się zbyt trudna w praktycznym wykorzystaniu. Może również nie spełniać obietnic, które ludzie z nią wiązali. W związku z tym jest przekonanie, że to, co mamy i używamy, jest na tyle istotne, że chcemy to zachować. 4. Wysoki koszt szkoleń Konkretnym powodem, który może hamować dalszy rozwój, stanowi koszt szkoleń. Szczególnie jeśli rozwój oznacza większy program szkoleniowy, wymagający angażowania trenerów i odejmujący ludzi od codziennej, projektowej lub rozwojo

Lessons Learned jest narzędziem pracy powszechnie stosowanym w zarządzaniu projektami (bardzo popularnym u kierowników projektów). Dowiesz się, dlaczego naszym zdaniem ta koncepcja jest antywzorcem? W tej rozmowie usłyszysz o ciągłym doskonaleniu procesu i produktu wraz z listą rekomendacji, co można zrobić, żeby uniknąć pułapki zbyt późnych usprawnień. Porządny Agile · Jak uniknąć pułapki Lessons Learned? Lessons Learned, czyli wyciąganie wniosków na końcu projektu, dla wielu wydaje się, być sensownym podejściem. Dowiedz się, dlaczego warto zrewidować tę koncepcję i jak efektywniej usprawniać produkty i procesy. Pomysł na poruszenie tego tematu pojawił się podczas konferencji dotyczącej zbierania wymagań. Jacek opowiadał na niej o tym, dlaczego koncepcja Lessons Learned jest bardziej antywzorcem niż polecaną przez niego praktyką. Wzbudziło to duże zainteresowanie i postanowiliśmy rozwinąć to zagadnienie.  Spis treści Czym jest Lessons Learned?Ciągłe doskonalenie procesuDlaczego warto się usprawniać?Ciągłe doskonalenie produktuPodejście iteracyjno-przyrostoweKorzyści z podejścia iteracyjno-przyrostowegoJak wprowadzić do zespołu podejście ciągłego doskonalenia procesu i ciągłego doskonalenia produktu?FAQ: Jak uniknąć pułapki Lessons Learned?📄Transkrypcja podcastu „Jak uniknąć pułapki Lessons Learned?” Czym jest Lessons Learned? Lessons Learned jest powszechnym narzędziem stosowanym w zarządzaniu projektami. Polega na tym, że bazując na dotychczasowych działaniach, zbiera się i podsumowuje wnioski. Na tej podstawie ustalane są w zespole projektowym potrzebne zmiany, np. w podejściu do pracy zespołu lub do sposobu działania procesów, czy też dostosowania narzędzi dla kolejnych projektów w przyszłości.  Najczęściej polega to na spotkaniu podsumowującym pracę po skończonym projekcie lub wdrożeniu. Cały zespół projektowy zastanawia się przez chwilę, co można było zrobić lepiej. Przemyślenia te i wnioski są spisywane, aby wiedziedzieć jak działać lepiej w przyszłości. Koncepcja Lessons Learned ma rację bytu, w sytuacji, gdy jest to jedyna rzecz, jaką ma zrobić zespół w ramach wyciągania wniosków, czy szukania usprawnień. Pozwala ona, chociaż w małym stopniu unikać ponownych błędów lub zawirowań. Jednocześnie Lessons Learned może być taktyką organizacji, która się uczy, a także w pewnym sensie elementem rozwoju osobistego członków zespołu, z których każdy nabiera coraz lepszych doświadczeń na temat tego, co działa, co nie działa, jak działać lepiej.  Z obserwacji niestety wiemy, że z implementacją tego podejścia bywa różnie, zwłaszcza gdy jest traktowana, tylko jako pewien punkt na liście do odhaczenia, zamiast stanowić szczerą refleksję. Często jest ona też realizowana już po skończonym projekcie, kiedy ludzie są już myślami w nowych zadaniach, zespoły się mieszają lub realizują całkowicie odmienne projekty. Bywa to też traktowane jako smutny obowiązek bez dostrzegania pozytywnych aspektów, które mogą usprawniać działanie w przyszłości.  Jednocześnie widzimy, że jest to po prostu zwykłe dokumentowanie pewnych wniosków i nacisk jest kładziony na to, żeby je dobrze spisać i to jest głównym celem ćwiczenia. Wnioski potem nie są wykorzystywane, a propozycji zmian nikt nie wdraża w życie. Bywa też tak, że ze spisanych przemyśleń korzysta zupełnie inny zespół, więc nie ma tu motywacji, żeby zrobić to rzetelnie. Ciągłe doskonalenie procesu Lessons Learned stoi trochę w kontrze z ciągłym doskonaleniem procesu, gdyż zgodnie z tym, co wspomnieliśmy powyżej, moment refleksji pojawia się trochę późno, bo na koniec projektu. Z kolei podejście ciągłego doskonalenia procesu sugeruje, aby takie ćwiczenie odbywało się częściej, np. co tydzień lub co 2 tygodnie albo po każdej iteracji czy innym rodzaju cyklu.   Koncepcja ciągłego doskonalenia podczas korzystania ze Scruma zwykle łączona jest z Retrospektywami Sprintu, natomiast my chcemy Cię zachęcić do podejścia, jakie znamy od Alistair’a Cockburn’a, czyli do nano-usprawnień. Są to takie, naprawdę drobne usprawnia, dzięki którym ciągle się doskonalimy, ciągle poprawiamy swój proces pracy i  sposób działania zespołu, usprawniamy przebieg spotkań, szukamy lepszych narzędzi czy taktyk. Stawiamy sobie tu proste pytanie: co działa, co warto wypróbować, a potem robimy małe kroki i przeprowadzamy drobne eksperymenty. Można to robić np. na koniec Daily, gdzie zespół odpowiada na pytania: jak bardzo wartościowe było to spotkanie, co działa dobrze, a co można by zrobić lepiej. Wystarczy dosłownie 5 minut rozmowy każdego dnia, gdyż to już po tygodniu może doprowadzić, że Daily stanie się satysfakcjonujące i przydatne dla wszystkich.  Nano-usprawnienia sprawdzą się w zasadzie przy każdej czynności, czy to w przypadku pojedynczego warsztatu z klientem, sesji planowania, czy Refinementu Backlogu Produktu. Nie ma tu potrzeby przeprowadzania jakiejś formy rozgrzewki, głosowania kropkami, czy długiej burzy mózgów. Wystarczy szybka rozmowa w zesp