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

Budowanie zaufania to kluczowy aspekt relacji klient-dostawca. Poznaj 4 aspekty tego procesu i zobacz, jak to możesz osiągnąć dzięki przejrzystości działań i komunikacji. Porządny Agile · Budowanie zaufania jako Software House Spis treści Czym jest zaufanie?Jak budować zaufanie w software house?FAQ: Budowanie zaufania jako software house📄Transkrypcja podcastu „Budowanie zaufania jako software house” Tytuł artykułu sugeruje, że jest skierowany głównie do firm typu software house, jednak naszym zdaniem jest to także ciekawa inspiracja dla wszystkich relacji klient-dostawca. Co istotne pojęcie klienta odnosi się zarówno do klienta wewnętrznego (biznes, inne rynki), jak i do partnerów z zewnątrz organizacji. W pierwszej części omówimy definicję zaufania, aby każdy z nas miał to samo zrozumienie. Następnie podamy cztery przykładowe aspekty budowania zaufania. Czym jest zaufanie? Zaufanie jest dla Jacka formą przekonania, że można na kimś polegać, a osoba, której zaufaliśmy, będzie postępować zgodnie z naszymi oczekiwaniami, wyobrażeniami i wartościami, a na końcu wywiąże się ze swoich zobowiązań. Z kolei dla Kuby zaufanie jest wiarą w przewidywalność zachowań osoby, z którą ma on relacje zaufania. Zaufanie bazuje tutaj na wiarygodności albo na dotychczasowych dobrych doświadczeniach współpracy z tą konkretną osobą. Oboje zgadzamy się z tym, że w realiach pracy w firmach typu software house zaufanie jest istotną płaszczyzną do budowania przyjaznych warunków pracy, dlatego zwykle firmy czy też zespoły chcą je rozwijać i utrzymywać. Obejrzyj nagranie na YouTube Jak budować zaufanie w software house? Nasze rekomendacje podzieliliśmy na 4 obszary, w ramach których opiszemy konkretne praktyki oraz podzielimy się wskazówkami opartymi na naszym doświadczeniu i obserwacjach. 1. Wiarygodność Spełniaj złożone obietnice Najprościej ujmując, chodzi tu o to, że jeśli obiecamy, że coś zrobimy, czy dopilnujemy, to dotrzymamy danego słowa. Przykładowo, jeśli obiecaliśmy klientowi, że przygotujemy draft projektu i wyślemy mu go do konkretnej daty, to spełnieniem naszej obietnicy, jest wysłanie tego draftu w ramach ustalonego terminu. Pomaga to zbudować poczucie niezawodności, a klient wie, że może polegać na wykonawcy. Zwiększa to też przewidywalność działań i pozwala klientowi planować różnego rodzaju aktywności związane ze zleconym projektem. Firmy bardzo poszukują tej przewidywalności, dlatego sami przeprowadzamy programy, w których pomagamy poprawić przewidywalność procesu wytwarzania. Przykładowo jeden z klientów Jacka dzięki takiemu 3-miesięcznemu wsparciu, poprawił przewidywalność zespołu z 43% do 78%. Komunikuj w przewidywalny sposób Chodzi tu o utrzymywanie komunikacji, zarówno tej operacyjnej, jak i wysokopoziomowej, w pewnym standardzie jakościowym. Standard ten powinien uwzględniać zawartość komunikacji, punktualność, responsywność i spójność, które świadczą o rzetelności partnera. Poczucie przewidywalności komunikacji budujemy poprzez np. w miarę stały czas odpowiedzi na maila klienta. Jeśli cały czas odpisywaliśmy na jego zapytania w ciągu godziny, zmiana tego schematu, może spowodować u klienta poczucie, że nie można polegać na zespole, bo jest nieprzewidywalny. Dobrym sposobem na uniknięcie powyższej sytuacji jest informowanie o okolicznościach, które mogą zaburzyć dotychczasowy sposób działania, np. integracja firmowa czy zmiana lokalizacji biura mogą na kilka dni wydłużyć czas oczekiwania na odpowiedź. Klient jest o tym uprzedzony i rozumie zaistniałe zmiany. 2. Komunikacja Informuj na bieżąco o ryzykach i problemach Bazując na doświadczeniach pracy w software house, jedną z gorszych rzeczy, jaką można zrobić, to stawianie klienta w sytuacji, w której dowiaduje się on na końcu o powstałych problemach w ramach jego projektu. Wytłumaczenie, że zespół nie chciał denerwować lub myślał, że się jednak uda, nie jest dobrym pomysłem. Klient może to odebrać jako zatajanie mniej pozytywnych elementów projektu i w efekcie obniżać zaufanie. Mocno rekomendujemy budowanie rzetelności od samego początku. Wiąże się to też z jak najwcześniejszym ostrzeganiem i wspólnym szukaniem rozwiązań, co wzmacnia poczucie partnerstwa i grania do tej samej bramki. Dziel się informacją zwrotną Odnosi się to zarówno do infomowania o rzeczach do poprawy, ale również do wzajemnego doceniania się oraz podkreślania, co wspiera pracę i ułatwia komunikację. Sposób dzielenia się informacją zwrotną z klientem zależy od relacji, jaką zespół ma z klientem i na jaką otwartość może sobie pozwolić. Zazwyczaj najbardziej oficjalnym sposobem jest forma pisana, głównie poprzez e-mail, rzadziej wiadomością na komunikatorze. Głównym minusem takiej formy komunikacji jest to, że klient otrzymuje suchy komunikat, a na to, jak go zinterpretuje, masz niewielki wpływ. Aspekty kulturowe dodatkowo wzmacniają potencjalny szum i niezrozumienie. Z tych też powodów uważamy, że w miarę możliwości lepiej wybierać rozmowę, zwłaszcza gdy obie strony widzą się nawz

Skąd się wzięła rola Agile Coach’a? Czy Scrum Master nie powinien być rolą tymczasową? To kilka pytań, na które odpowiedzi usłyszysz w tej rozmowie. Poruszyliśmy też temat budowania wiedzy produktowej u nowego Product Ownera, zwolnień w pracy zwinnej i relatywnego szacowania. O wszystkie zapytali nasi Słuchacze – tym materiałem dokończyliśmy pulę pytań, które do nas dotarły, gdy o nie poprosiliśmy. Porządny Agile · Q&A cz.2 Podobnie jak poprzednio wpis będzie miał formułę „pytanie-odpowiedź”. Przy niektórych, bardziej obszernych pytaniach, przyjęliśmy pewne założenia, o których wspomnimy. Ponieważ na pytania odpowiadamy dosyć spontanicznie, to może się zdarzyć, że nasze wypowiedzi będą trochę ze sobą sprzeczne lub nawiążemy do wątków pobocznych. Spis treści Nowy Product Owner w Zespole Scrumowym. Jak budować wiedzę produktową?Jak weryfikować czy kandydat nadaje się do pracy zwinnej?Jak estymować z wykorzystaniem relatywnego szacowania w mocno wyspecjalizowanych zespołach?Skąd się wzięła rola Agile Coach’a?Dlaczego firmy zatrudniają Scrum Masterów do zarządzania zespołami zamiast do pomocy organizacji?Czy Scrum Master nie powinien być rolą tymczasową, aby budować odpowiedzialność w zespole?FAQ:  Q&A cz.2📄Transkrypcja podcastu „Q&A cz. 2” Nowy Product Owner w Zespole Scrumowym. Jak budować wiedzę produktową? W pytaniu widzimy założenie, że nowy Product Owner w zespole może mieć braki w wiedzy produktowej. Prawdopodobnie osoba ta ma predyspozycje do pełnienia swojej funkcji, brak jej po prostu doświadczenia z tym konkretnym produktem i zespołem.  W ramach budowania wiedzy produktowej rekomendujemy wykonanie poniższych kroków: 1. Zrozumienie produktu, wizji i strategii: Zapoznanie się z istniejącą dokumentacją, taką jak wizja produktu, strategia produktowa, roadmap itp. Jeśli dokumenty te nie są dostępne, to zidentyfikowanie osób, które pomogą zbudować te artefakty. Wypracowanie razem z zespołem wspólnego rozumienia produktu, jego celów i wartości dla użytkowników. Uspójnienie wiedzy dotyczącej kierunku, w którym produkt ma się rozwijać i w jaki sposób będziecie realizować cele biznesowe, które przed tym produktem są postawione. 2. Okres przejściowy: Zorganizowanie okresu przejściowego z dotychczasowym Product Ownerem lub Product Ownerką. Wykorzystanie tego czasu na wtajemniczenie w kontekst produktu, jego historię, wyzwania i sukcesy. Zaproszenie do procesu przekazywania wiedzy też innych osób pracujących z produktem, ale i Product Ownerów czy Product Ownerki z zespołów blisko współpracujących. Aktywne uczestniczenie w dyskusjach i zadawanie pytań, zamiast ograniczania się tylko do czytania dokumentacji. 3. Budowanie relacji i poznawanie różnych perspektyw: Zbudowanie mapy Interesariuszy i osób, które długo pracują w organizacji, aby poznać różne perspektywy, ale i więcej dowiedzieć się o historii produktu czy potrzebach odbiorców. Wykorzystanie spotkań z tymi osobami do budowania relacji i pozycji, aby wejść w realia tego produktu. 4. Odłożenie w czasie budowania Backlogu: Powstrzymanie się przed układaniem Backlogu. Skupienie się najpierw na poznawaniu produktu i jego otoczenia. Jak weryfikować czy kandydat nadaje się do pracy zwinnej? Pozwoliliśmy sobie trochę sparafrazować i skrócić otrzymane pytanie. W pełni brzmi tak: „Czy zdarzyło Wam się doprowadzić do zwolnienia kogoś, kto nie nadaje się do pracy zwinnej? Czy waszym zdaniem takie sytuacje nie powinny się zdarzać częściej, niż się zdarzają? Mam poczucie, że zwinność jest czymś premium, do czego naprawdę dużo osób nie pasuje. Nie chcę w tym pytaniu oceniać negatywnie tych ludzi, natomiast zwinność moim zdaniem jest wspierana przez pewne cechy osobowości, a przez inne jest mocno utrudniona. Jak weryfikowalibyście na etapie rekrutacji nadawanie się kandydata do pracy zwinnej?” Możemy przyjąć, że mówimy tu o pewnej formie selekcji osób, które mają pracować zwinnie. Jak weryfikować takie osoby, jak upewniać się, że osoby, które mamy w procesie rekrutacji, sprawdzą się w pracy w środowisku zwinnym. Kubie zdarzały się sytuacje związane z agile, w których osoby nie pasowały do pracy zwinnej. Najczęściej problem dotyczył nie tyle samej zwinności, ile umiejętności pracy zespołowej. Współdziałanie jest fundamentem zwinności, a nie każdy czuje się z tym komfortowo. Całkiem możliwe, że nie jest to kwestia osobowości, a zwykłych przyzwyczajeń. Ktoś to długo pracował całkowicie samodzielnie, mógł zatracić umiejętność czy nawet chęć współpracy. Ważne jest, aby dawać szansę na dostosowanie się. Zwłaszcza w zespołach, które dopiero startują w danej organizacji albo składają się z ludzi, którzy do tej pory tak nie pracowali. Warto zadbać też o podstawy związane z zasadami jakościowej komunikacji, z dawaniem sobie feedbacku, ustaleniem zasad współpracy.  Jeśli natomiast osoba upiera się przy swojej postawie i nie wykazuje ochoty na współpracę, to jest jasny sygnał, że będzie źle funkcjonować w zespole zwinnym

Czy Scrum Masterzy rzeczywiście słabo wykonują swoją pracę? Co daje nam największy napęd w szerzeniu “zwinności”? Czy agile umiera? Słuchacze pytają, a my odpowiadamy. W pierwszej rozmowie z cyklu Q&A wybraliśmy osiem pytań od naszych słuchaczy i odpowiedzieliśmy na nie. Porządny Agile · Q&A cz.1 Pytania te dotyczą różnych aspektów zwinności, od codziennych praktyk po zarządzanie zespołem i skalowanie. Nie są to wszystkie, które otrzymaliśmy, gdyż było ich bardzo dużo. W niedalekiej przyszłości wybierzemy kolejne kilka pytań, aby odpowiedzieć na jak najwięcej z nich. Spis treści Jak monitorować i prezentować zespołowi codziennie Action Pointy z Retro w pracy zdalnej?Co daje Wam największy napęd („drive”) w szerzeniu zwinności?Jaka jest rola Scrum Mastera w procesie Release w Scrumie?Co w sytuacji, gdy Product Owner nie chce interesariuszy na Review, „bo nie ma co pokazać”?Czy obserwujecie, że wielu Scrum Masterów słabo wykonuje swoją pracę?Z jakich powodów agile umiera?Jak przekonać firmę do deskalowania zamiast skalowania, gdy nie ma do tego warunków?Jak pracować z ludźmi posiadającymi waterfall’owy mindset? 📄Transkrypcja podcastu „Q&A cz.1” Jak monitorować i prezentować zespołowi codziennie Action Pointy z Retro w pracy zdalnej? W pytaniu tym widzimy pewne założenie, że wcześniej, czyli przed pracą zdalną takie akcje usprawniające były monitorowane. Drugą rzeczą, która rzuciła nam się w oczy to, przeświadczenie, że za monitorowanie i prezentowanie akcje usprawniające odpowiada jedna osoba. Czy zawsze jest to Scrum Master lub lider? Z tym drugim założeniem nie do końca się zgadzamy. Naszym zdaniem odpowiedzialność tego typu powinna spoczywać na całym Zespole zwinnym. Nim przejdziemy do propozycji monitorowania i prezentowania Action Pointów, warto zastanowić się, gdzie leży problem. Dlaczego teraz to sprawia trudność? Być może problem tkwi w ich sformułowaniu – jeśli są one jasne i precyzyjne, łatwiej je zrealizować i monitorować. Ponadto być może jest ich za dużo, skoro muszą być monitorowane? Warto zastanowić się, czy wszystkie ustalenia są niezbędne i czy nie można ich zredukować do najważniejszych. Jak prezentować i śledzenia akcje usprawnieniowe? Poszukaj wygodnej dla zespołu formuły wizualizacji ich w narzędziach online, Uwzględnij akcje usprawniające w Backlogu Produktu i Backlogu Sprintu. Przygotuj je w formie listy i spraw by była wyświetlana podczas Stand-upu, podobnie jak to się robi z listą tematów do wytworzenia, Regularnie wracaj do ustalonych Action pointów i przypominaj o nich Zespołowi, Zadbaj o szybką realizację ustaleń, w ten sposób problem monitorowania może stać się mniej istotny. Oceniaj z całym Zespołem efektywność wdrażanych akcji usprawniających i w razie potrzeby modyfikuj stosowane podejście. Co ważne, zachęcamy, aby nie porzucać spotkań i działań usprawniających, gdyż są one kluczowe dla rozwoju zespołu. Co daje Wam największy napęd („drive”) w szerzeniu zwinności? Pewnie nie odważylibyśmy się zrobić całego materiału na ten temat, ale nasza odpowiedź może być pewną inspiracją dla Ciebie. Dla Kuby fascynujące jest to, że zwinność pozwala łączyć korzyści biznesowe z dobrymi warunkami pracy dla zespołów. Biznes jest zadowolony, bo agile daje profity, a jednocześnie członkowie zespołu lepiej działają, bo są częścią prawdziwego zespołu. Wszyscy skupiają się na konkretnych rzeczach, co zapewnia lepsze warunki pracy i jednocześnie daje namacalne rezultaty dla organizacji. Patrząc historycznie, praca w zespole bez poczucia celu i w izolacji biznesowej była frustrująca. Zwinność stawia na bliską współpracę. Dla Jacka było to jednym z powodów, przez które zdecydował się porzucić programowanie i zajął się zarządzaniem projektami. Co więcej, prawidłowo zastosowana zwinność daje poprawne rezultaty. Lubimy sensowne i przemyślane produkty, które działają i są porządne. Zwinność, oparta na eksperymentowaniu i wczesnym włączaniu klienta, daje właśnie takie efekty. Tworzone produkty są proste i zawierają wszystko, co jest potrzebne. W całym pytaniu Słuchacza jest też nawiązanie do kwestii perspektyw zarobkowych. Jest to oczywiście bardzo subiektywne. Wiele zależy od tego, jak pokierujesz swoją karierą, czy będziesz się wciąż rozwijać i próbować nowych podejść. Jeśli chodzi o nas faktycznie, okazało się to dla nas opłacalne, jednak to nie zarobki były czy są głównym driverem. Spokojnie moglibyśmy pracować jako managerowie lub programiści, a zarobki może byłyby nawet lepsze. Oczywiście dzięki pracy chcemy zapewnić byt naszym rodzinom. Mieliśmy mnóstwo alternatywnych ścieżek kariery, ale tym bardziej stanęliśmy po stronie zwinności. Warto jednak podkreślić, że agile jest wabikiem dla wielu osób, które chcą wejść do IT. Motywator finansowy jest istotny i nie można go ignorować. Natomiast w naszym przypadku nie był on decydujący. Jaka jest rola Scrum Mastera w procesie Release w Scrumie? Może panować przekonanie, że proces wdrażania pro

Zastanawiasz się, czy wykorzystanie agile poza IT jest możliwe? W ostatnich latach owocnie współpracowaliśmy z firmami z innych branż niż IT i mamy listę przemyśleń na temat na temat wykorzystania zwinności w obszarach innych niż wytwarzanie oprogramowania. Porządny Agile · Agile poza IT Czy zwinność może stać się kluczowym narzędziem transformacji organizacyjnej w różnych sektorach? Jakie są wyzwania związane z wprowadzeniem praktyk Agile w obszarach spoza IT?  Spis treści Jak wykorzystać Agile poza IT – nasze przemyśleniaFAQ: Agile poza IT📄Transkrypcja podcastu „Agile poza IT„ Przyjrzyjmy się temu, jak zwinność może zostać wdrożona w firmach lub ich częściach, które niewiele mają wspólnego z nowymi technologiami. Na co się przygotować i jak podejść do napotkanych wyzwań?  Do tematu zwinności poza IT zainspirowały nas wyniki jednej z ankiet wypełnianych przez słuchaczy podcastu Porządny Agile. Doświadczenie w tym obszarze zebraliśmy dzięki współpracy z licznymi organizacjami spoza świata IT, gdzie występowaliśmy jako konsultanci lub trenerzy. Jak wykorzystać Agile poza IT – nasze przemyślenia 1. Zwinność poza IT jest możliwa Pomimo że zwinność zwykle kojarzy się ze światem technologicznym, to dysponujemy licznymi przykładami z naszej praktyki zawodowej, gdzie Agile wykorzystywano w np. w firmach z branży medycznej, usługowej, produkcyjnej (niezwiązanej z wytwarzaniem oprogramowania). Tak naprawdę zwinność może sprawdzić się tam, gdzie pojawia się konieczność pracy zespołowej, nawet jeśli dotyczy to tylko wycinka funkcjonowania organizacji. Często pojawia się taka potrzeba w działaniach na poziomie strategicznym, ale i gdy firma zmienia sposób funkcjonowania linii produkcyjnej, wprowadza nowy produkt na rynek, szuka i wymyśla innowacje w sposobie tworzenia rozwiązania, a także w sytuacji przeprowadzania zmian w organizacjach. 2. Agile nadaje się do zespołowego rozwiązywania złożonych problemów Wcześniej wspomniane przykłady wykorzystania zwinności poza IT to często bardzo złożone problemy, zwłaszcza jeśli mówimy o zmianach na poziomie całej firmy. Bez ustrukturyzowanej pracy zespołowej, efektywność realizacji działań może być daleka od oczekiwanej. W tego typu projektach niezbędny jest współpracujący zespół, złożony z różnych specjalistów z niezbędnymi kompetencjami. Często są to być osoby z różnych działów czy z poziomów w hierarchii organizacyjnej. Złożone projekty, gdy nikt nie ma gotowego pomysłu na działania, wymagają eksperymentowania. Próbuje się różne podejścia, wyciąga wnioski, przeprowadza pilotaże i zbiera feedback od interesariuszy.  Przykładem może być sytuacja, w której działania konkurencji osłabiają pozycję lidera na rynku. Być może zaczęli dostarczać na rynek usługi czy produkty, które są lepsze i trafiają do szerszego grona odbiorców. Przy wykorzystaniu konkretnych praktyk zwinnych, można spróbować zająć się tym problemem. Te konkretne techniki to m.in. multidyscyplinarny zespół projektowy, praca małymi krokami oraz nieustanne zbieranie informacji zwrotnej odnośnie do tego, co tworzymy. 3. Zwinność nie jest do wszystkiego Istnieje pewien mit, mówiący, że zwinność nadaje się wszędzie i można go wykorzystać praktycznie w każdej części organizacji. Nie jest to prawdą, a co więcej może powodować pewną presję wśród pracowników, którzy wykonując jakieś proste i powtarzalne działania, nie do końca dostrzegają, jak podejście zwinne lub jakie konkretne taktyki mogłyby im pomóc. Takie niezrozumienie może więcej szkody niż pożytku, włączając w to niechęć pracowników do jakichkolwiek zmian w organizacji lub ich zespole. Dlatego warto dobrze przemyśleć, czy to nowe podejście, które nas tak zachwyciło, sprawdzi się tam, gdzie chcielibyśmy je wykorzystać. Współpracując z fabryką produkującą auta, Kuba został zapytany przez jednego z zarządzających, czy auta też będą produkować z wykorzystaniem Agile. Szybko postawili sobie jasną granicę, że akurat w przypadku produkcji aut, gdzie proces jest powtarzalnym schematem, z ustalonymi narzędziami i procedurami, Agile się nie przyda. Jednak Kuba zaproponował, że miejsce na zastosowanie podejścia zwinnego, będzie, jak np. firma będzie chciała wprowadzić nowe auto na linię produkcyjną, albo zmodernizować sposób działania obecnej linii produkcyjnej, czy też przyjrzeć się jakiemuś aspektowi funkcjonowania organizacji. Podsumowując. Zwinność nie będzie dobrym podejściem zazwyczaj tam, gdzie jest proces, procedura, utrwalone zasady działania. Warto zwracać na to uwagę, aby nie zapędzić się ze wdrażaniem zwinności wszędzie i aby nie zrazić do niej pracowników, przez próbę wykorzystywania technik nieadekwatnych miejsca czy działań.  4. Zwinna transformacja jest trudniejsza niż się wydaje Osoby zarządzające organizacją, gdy inspirują się Agile’em, mogą nie zrozumieć, jak wielka zmiana ich czeka. Wykorzystanie praktyk zwinnych to nie tylko spotkania zespołów lub wydanie polecenia, że od dziś działamy w ten sposób. Jest to

Jesteś osobą odpowiedzialną na zmianę w organizacji i czujesz, że nic więcej nie da się zrobić? Czasami warto odpuścić. Poznaj siedem sygnałów, które naszym zdaniem na to wskazują. Wyjaśniamy też nasz punkt widzenia na temat odpuszczania. Porządny Agile · O tym, kiedy odpuszczać Jak poznać, że pora zmienić organizację, gdyż w obecnej nie da się już nic więcej dokonać bez narażania się na wypalenie? Na co zwracać uwagę i co jest być pomocne w podjęciu tej decyzji? Spis treści Czym jest odpuszczenie?7 oznak, że warto odpuścićFAQ: O tym, kiedy odpuszczać📄Transkrypcja podcastu „O tym, kiedy odpuszczać” Czym jest odpuszczenie? Można powiedzieć, że o odpuszczaniu mówimy, kiedy wspierasz organizację w procesie zmiany, jednak jest pasmo ciągłych przeszkód i niepowodzeń. Masz poczucie, że nie ma postępu, a wszystkie możliwe sposoby i pomysły na wdrożenie usprawnień zostały wyczerpane. Starasz się z całych sił, brakuje Ci wsparcia, zaczynasz tracić energię i motywację. Pewnego dnia po prostu stwierdzasz, że wachlarz możliwości się wyczerpuje i pojawia się uczucie, że tracisz czas. Czas, który można wykorzystać w innej firmie, której naprawdę zależy na zmianie, a Ty będziesz mieć szansę zrobić wreszcie coś namacalnego. Rezygnujesz, zwyczajnie odpuszczasz starania. Oczywiście, uczucia mogą tutaj pojawić się różne. Powyższy opis dotyczy tego, co sami odczuwaliśmy, kiedy byliśmy w podobnych sytuacjach. Chcieliśmy pokazać Ci, jak to może wyglądać, bazując na realnym przykładzie, prawdziwej sytuacji z życia.  7 oznak, że warto odpuścić Poniższa lista nie jest zamknięta. Jest to pewna synteza tego, co sami doświadczyliśmy i może to być dla Ciebie pewną wskazówką, że znajdujesz się w ślepej uliczce. 1. Działasz z wyraźnie mniejszą energią niż kiedyś Chodzi nam tu o sytuacje, gdy orientujesz się, że potrzebujesz dodatkowej energii i motywacji do działań, które kiedyś były robione z ochotą, napędzało do dalszej pracy. Czujesz, że coraz bardziej nie chcesz tego robić, szukasz wymówek lub zmuszasz się do wykonywania zadań z tego obszaru. To mocny sygnał, że pora odpuścić. I nie ma w tym nic złego. Sami mieliśmy też takie sytuacje, a najlepsze co możesz dla siebie zrobić to zatrzymać się i zastanowić się, co się dzieje i czy warto dalej walczyć. 2. Nie dostrzegasz istotnych sojuszników zmiany Działania z każdą zmianą, czy to w organizacji, w zespole, w produkcie czy w sposobie działania, są pracą zespołową. Zazwyczaj pracujesz z jakimś liderem, może programistą, testerami i analitykami. Osoby te pojawiają się w odpowiednich momentach i Cię wspierają. Jednocześnie wszyscy się wzajemnie nakręcacie i inspirujecie. Jeśli jednak nie ma tych osób, bo np. odsunęły się lub odeszły, to zaczyna się robić niebezpiecznie. Twoje wysiłki mogą przestać być tak skuteczne, jak do tej pory, gdyż trudno jest samodzielnie przeprowadzić jakąś zmianę, zwłaszcza w dużej organizacji. Ważny jest też tu też aspekt ludzki, wspieranie w trudniejszych momentach, odbijanie pomysłów i wspólne świętowanie sukcesów. Przykładowo, Kuba miał nawet taką sytuację, kiedy to zespół tak dobrze zorganizował pracę w agile, że ich lider awansował i przestał wspierać zespół, jak do tej pory. 3. Chęć zmiany w organizacji okazała się wyłącznie fasadowa To chyba jeden ze smutniejszych momentów, gdy osoba zaangażowana w zmianę, zaczyna dostrzegać, że tak naprawdę ta zmiana nie jest oczekiwana. Nie chodzi nam o to, że rzeczy dzieją się powoli, bo to oczywiste, że w większych organizacjach to tempo może być wolniejsze. Jednak, gdy dociera do Ciebie, że tak naprawdę poza bardzo powierzchownymi zmianami, więcej się raczej nie zmieni, jest to mocny sygnał do zastanowienia się, czy na pewno jesteś we właściwym miejscu. Przykładowo musisz z zespołem zaakceptować, że osoby z biznesu nie będą reprezentantami klienta i nie dostarczą bardzo cennego feedbacku. Długofalowo nie wróży to nic dobrego. Przykładem jest sytuacja, która spotkała Kubę i która była jednym z takich kamyczków dorzuconych do puli argumentów za tym, że ta zmiana, nad którą pracują, nie nastąpi, że chęć zmiany jest tylko powierzchowna. Działaliśmy w Scrumie, niby rzeczy jakoś tam się działy. Jednak gdy przyszło do rozmowy z zarządem o potrzebie powiększenia zespołów, gdyż nie byliśmy już w stanie zrealizować wszystkich celów strategicznych, pojawił się opór. Pojawił się on też, gdy chcieliśmy pewne rzeczy zmienić, aby usprawnić pracę i przyspieszyć procesy. Brak wsparcia managementu i prawdziwej chęci zmian jest mocnym sygnałem, że może warto odpuścić. 4. Zmiana nie przynosi widocznych rezultatów Wiele zmian potrzebuje czasu na to, żeby zobaczyć pierwsze rezultaty. Jeśli jednak pomimo podjętych prób, zrealizowania wszystkich założeń i działań zgodnie z planem, zmiana nie następuje, to też jest sygnał, aby się zatrzymać i zastanowić nad sytuacją. Być może coś robisz źle, być może plan był nieidealny, a może w tej konkretnej organizacji nie da się zrealizować tej konkretnej zmiany. Oczywiście nie mówimy o

Przedstawiamy nasze wrażenia ze szkolenia u Alistair’a Cockburn’a “Advanced Agile Masterclass”. Tym razem to nie my szkoliliśmy, a poszerzyliśmy naszą wiedzę u jednego z inicjatorów Manifestu Agile. Opowiemy Ci, jakie mamy przemyślenia po i co nas zainspirowało. Porządny Agile · Po szkoleniu Advanced Agile Czy warto wziąć udział w szkoleniu Alistair’a Cockburn’a z zaawansowanego agile? Czego można się na nim nauczyć i czy osoby ze sporym doświadczeniem w pracy z agile wyciągną z niego jakąś wartość? Spis treści Jak Alistair Cockburn prowadzi warsztaty?Ogólne refleksje po wa warsztatach Advanced AgileFAQ: Po szkoleniu Advanced Agile📄Transkrypcja podcastu „Po szkoleniu Advanced Agile” Opowiadając o zaawansowanej zwinności w 113. odcinku podcastu Porządny Agile, nawiązaliśmy do szkolenia Advanced Agile prowadzonego przez Alistair’a Cockburn’a, w którym ostatnio uczestniczyliśmy. Wyciągnęliśmy z niego trochę wniosków i inspiracji, którymi podzielimy się w tym artykule. Przy okazji opowiemy kilka przygód, które się nam przytrafiły podczas wykonywania ćwiczeń.  Jak Alistair Cockburn prowadzi warsztaty? Alistair Cockburn jest osobą, która w pewnym sensie nas ukształtowała. Na początku naszej przygody ze zwinnością, spędziliśmy cały tydzień w jednej z organizacji, współpracując z Alistair’em. Możliwość interakcji z nim na wczesnym etapie naszego rozwoju oraz śledzenie jego aktywności w Internecie, spowodowały, że stał się dla nas ogromną inspiracją. To z kolei sprawiło, że możliwość zobaczenia po latach, jak prowadzi warsztaty, w jaki sposób wchodzi w interakcje z ludźmi, jak odpowiada na pytania, jak wprowadza do ćwiczeń lub jak daje feedback, było dla nas bardzo interesujące.  Korzystał on z bogatej w slajdy prezentacji, którą otrzymaliśmy w wersji wydrukowanej. Sami nie jesteśmy fanami drukowania prezentacji. Wynika to z jednej strony ze względów ekologicznych, z drugiej strony zwykle powodują zamieszanie (coś się nie wydrukuje, trzeba je dobrze poukładać itd.). Jednak jako uczestnicy stwierdzamy, że było to przydatne i ułatwiało robienie notatek.  Podobnie, jeśli chodzi o korzystanie z flipchartów, Alistair w przeciwieństwie do nas, nie korzystał z nich. Dyskusje toczyły się na głos, a dzięki temu Alistair nie skupiał się na pisaniu na flipcharcie, miał lepszą uwagę i dokładniej nas słuchał. Motywowało to też uczestników do większej uważności i robienia lepszych notatek.  Pewnym zaskoczeniem dla nas było to, że szkolenie było o porządnych podstawach zwinności, a nie jak na to wskazywała nazwa, o jej zaawansowanych aspektach. Rozmawialiśmy o fundamentach w zwinności, jednak bardzo dużo było ćwiczeń i okazji do zderzenia różnych punktów widzenia i wymiany doświadczeń. Natomiast dzięki temu, że raczej nie było na szkoleniu początkujących, tylko raczej osoby, które długo siedzą w agile, poziom dyskusji był naprawdę wysoki. Widać było, że nawet jeśli mówimy tylko o bardzo podstawowych rzeczach, to wybrzmiewało z nich duże doświadczenie uczestników. Zresztą sam Alistair często pokazywał, że pewne podstawy dalej są tym samym i zawsze są tak samo istotne. Pojawił się tu koncept Shuhari, w którym to najpierw podąża się za instrukcjami, potem łamie się te poszczególne wytyczne instrukcji, a na końcu dochodzi do tworzenia swoich własnych, lepiej dopasowanych do nas instrukcji.  Innym podejściem, który Alistair mocno ostatnio promuje, jest Kokoro, czyli poszukiwanie prostego języka, wyrażenie pewnych koncepcji w jak najprostszej postaci. Jest postawa osoby (np. trenera), który wyjaśnia skomplikowane rzeczy w bardzo prosty sposób. Mamy tu takie przełamywanie swojej eksperckości i, pomimo że się zna pewne rzeczy na zaawansowanym poziomie, to bardzo świadome upraszcza się ten komunikat, aby odbiorca dobrze zrozumiał istotę tego, co chcemy przekazać. Mocno widoczne to podejście było, gdy Alistair na bazie wykresów opowiadał o zarządzaniu ryzykiem czy przerywaniu pracy, gdy nie przynosi żadnej wartości dodanej. Mówił prostym językiem, bez omawiania złożonych frameworków lub skomplikowanych nazw, aby podkreślić swoją wiedzę i eksperckość. Można powiedzieć, że wręcz radykalnie upraszczał swój komunikat, aby rzeczywiście trafić do odbiorcy.   Ciekawym ćwiczeniem o bardzo prostej konstrukcji było “Dokończ zdanie”. Przykładowo  “Zwinność jest mniej wydajna niż Waterfall, ponieważ…”. Robiliśmy je w grupach i nawet pojawiły się sytuacje, w których niektórzy uczestnicy próbowali troszkę zaatakować sam pomysł rozmowy o tym, że zwinność jest mniej wydajna, że Waterfall jest lepszy niż Agile. Jednakże Alistair był na to przygotowany i świetnie nas pokierował na pewną pulę przemyśleń. Sam zresztą śmiał się, że czasem wrzuca do Internetu tego typu stwierdzenia, co też zrobił w trakcie ćwiczenia. Pojawiła się burza komentarzy, niezrozumienia, uproszczeń, ataków i kontrataków. Na końcu ćwiczenia jednak pojawiło się istotne przemyślenie, że podejście zwinne jest mniej

Jak mogą wyglądać elementy Backlogu Produktu, czyli potocznie story lub storki? Dowiesz się, jak takie porządne story powstaje i z jakich elementów się składa. Podajemy też przykładowy szablon zawartości dobrego story. Porządny Agile · Porządne story Dowiedz się jak stworzyć porządne story, które dzięki wykorzystaniu wizualizacji, pracy w podgrupach i eksperymentowaniu, może znacząco usprawnić pracę zespołu i zwiększyć jakość wytwarzanego produktu. Spis treści Jak powstaje porządne story?Propozycja szablonu historyjkiFAQ: Porządne story📄Transkrypcja podcastu „Porządne story” Inspiracją do poruszenia tego tematu jest doświadczenie Kuby ze współpracy z pewnym zespołem Product Ownerów. W trakcie rozmów pojawiła się kwestia praktycznego podejścia do Backlogu Produktu. Powstały się wówczas różnego rodzaju historyjki, a tym samym okazja do wprowadzenia drobnych poprawek oraz wskazania punktów, które są wartościowe i warto propagować je dalej. Dlatego w tym artykule przekażemy Ci nasze rekomendacje związane z tworzeniem porządnego story, czyli inaczej elementu Backlogu Produktu. Mówiąc o story, mamy właśnie na myśli właśnie element, który chcemy mieć w produkcie i potrzebujemy go nazwać i określić. Jak powstaje porządne story? Nim przejdziemy do rekomendowanego przez nas szablonu story, podzielimy się z Tobą kilkoma wskazówkami: 1. Twórz Backlog Produktu całym Zespołem  Jedną z możliwych przyczyn niedoskonałych Backlogów Produktu lub pojedynczych stories jest to, że są realizowane przez jedną osobę. Nie ma znaczenia czy jest to Product Owner, analityk czy jeszcze inna osoba, w każdym przypadku, taka historyjka będzie bardzo jednostronna i całkiem możliwe, że niekompletna. Dlatego mocno rekomendujemy, aby w Twoim zespole stories były tworzone przez wszystkich jego członków. Pozwoli to zebrać wiele perspektyw od różnych specjalistów i stworzyć jak najbardziej kompletne story. Jednocześnie jest to dobra okazja do budowania odpowiedzialności zespołu za rozwiązanie i do zrozumienia kontekstu biznesowego, w którym ono powstaje.  2. Korzystaj z wizualizacji  Interpretowanie tekstu pisanego często niesie ze sobą zagrożenie tzw. głuchego telefonu i całkowite przeinaczenie pierwotnego przekazu. Aby upewnić się, że wszyscy w zespole rozumieją tak samo problem lub zadanie do wykonania, zaproponuj wykorzystanie z wizualizacji. Mamy tu na myśli różnego rodzaju schematy, diagramy, naszkicowane wersje interfejsu lub inne formy graficzne, które obrazują to, o czym rozmawiacie. Możesz to zrobić, biorąc kartkę i długopis i najprościej jak potrafisz, narysuj, to co omawiacie. Oczywiście, jeśli masz możliwość, to skorzystaj z tablicy czy whiteboardu, które są dostępne w wielu programach do spotkań online. Rekomendujemy Ci to, ponieważ z doświadczenia wiemy, że zespoły w większości przypadków przepracowują na tyle skomplikowane zadania, że samym tekstem trudno oddać istotę rzeczy, a ryzyko błędnej interpretacji jest dosyć wysokie.  3. Eksperymentuj z pracą w podgrupach  W pierwszej wskazówce mówiliśmy o angażowaniu całego zespołu do pracy nad Backlogiem Produktu, jednak niektóre czynności można przyspieszyć, rozdzielając zadania pomiędzy kilkuosobowe grupy. Każda z takich grup we własnym gronie przepracowuje zadany temat, a potem przedstawia go reszcie zespołu. Można również pracować w grupach symultanicznie nad tym samym zagadnieniem, aby później poznać różne perspektywy. Praca w mniejszych grupach ma tę zaletę, że działając w kilkunastoosobowym zespole, może rodzić się pokusa siedzenia cicho, bo w końcu jest tyle osób, które może to zrobić za mnie. Natomiast pracując w mniejszej grupie osób, jest szansa, że wszyscy będą aktywni, gdyż trudniej się ukryć i tylko udawać zaangażowanie.  4. Unikaj pośredników Zwróć uwagę na to, żeby tam, gdzie jest to możliwe, skracać łańcuch osób, które przekazują sobie informacje. Im mniej pośredników, tym większa szansa na uzyskanie konkretnej i właściwej informacji. Staraj się rozmawiać bezpośrednio z osobami, które są odpowiedzialne za poruszany temat. Dobrą praktyką jest też, zaproszenie tej osoby do rozmowy z całym zespołem. Wówczas wszyscy członkowie tego zespołu mają szansę dopytać o konkretne szczegóły i uzyskać z pierwszej ręki potrzebne Wam informacje. Dodatkową zaletą zaproszenia interesariuszy do współpracy jest to, że później można zaangażować ich w proces, np. przy tworzeniu wizualizacji czy do pracy w podgrupach. Taka zewnętrzna perspektywa jest często bardzo cenna i pozwala np. na szybsze uzyskanie informacji zwrotnej lub wsparcie przy bardziej skomplikowanych zagadnieniach.  5. Ciągle usprawniaj stosowane praktyki. Jeśli w Twoim zespole została wypracowana konkretna propozycja rozwiązania czy plan działania, nie oznacza to, że nie można tego usprawnić w ramach kolejnych Retrospektyw. Podobnie, jeśli odkryty zostanie jakiś sprawdzony wzorzec postępowania, który przynosił dobre efekty, warto dalej eksperymentować. Wraz z Zespołem, ciągle przesuwajcie so

Co robić gdy słyszysz od zespołu, że “tego nie da się tego zrobić?”. Z czego może wynikać to założenie? Poznaj siedem porad, które pomogą Ci zmienić nastawienie Twojego zespołu. Porządny Agile · #114 – Zespół mówi “nie da się” Czy zdarzyło ci się kiedyś, że Twoi współpracownicy utknęli w przekonaniu, że tylko jedno doskonałe rozwiązanie istnieje, ale niestety jest poza zasięgiem? Takie sytuacje mogą prowadzić do paraliżu i braku pomysłów na działanie.  Spis treści Dlaczego zespół mówi “nie da się”? Co zrobić, gdy zespół mówi “nie da się”?FAQ: Zespół mówi „nie da się”📄Transkrypcja podcastu „Zespół mówi “nie da się”” Jak zatem pokonać pułapkę idealnego rozwiązania w zespole? W dzisiejszym artykule chcielibyśmy podzielić się naszym doświadczeniem na temat tego, jak wydobyć zespół z takiej pułapki myślenia. Najpierw opowiemy o naszych hipotezach dotyczących źródła takiego podejścia zespołu, a następnie przejdziemy do wskazówek pomagających poradzić sobie z tą sytuacją. Dlaczego zespół mówi “nie da się”?  1. W przeszłości się nie udało i zespół ma w głowie, że “kiedyś próbowaliśmy i nam nie wyszło, więc to nie ma sensu”. Na tej bazie w zespole może wytworzyć się poczucie, że to już nie uda się nam nigdy w przyszłości, bo w końcu w przeszłości nam nie wyszło. 2. Wcześniejsza inicjatywa zmiany była ukarana, a w głowach członków zespołu jest myśl “kiedyś próbowaliśmy, ale dostaliśmy po łapach za sam fakt spróbowania inaczej”. Z takim doświadczeniem, zespół może być dużo bardziej ostrożny i niechętny do podobnych inicjatyw.  3. Istnieją ukryte założenia, a zespół mówiąc, że “nie da się” ma na myśli to, że np.  nie da się w tym budżecie, który mamy,  nie da się przy sposobie zarządzania w naszej organizacji, nie da się w naszym stacku technologicznym. To takie konkretne, ale niewypowiedziane na głos założenia, które powodują, że zespół się blokuje nie na poziomie obiektywnym, ale na poziomie warunków, jakie ma.  4. Jest to mechanizm obrony, a zespół chce szybko zbyć pomysłodawcę nowej koncepcji. 5. Zespół nie ma czasu, czego powodem może być np. szczyt sezonu, jakaś presja czasu lub mało przychylny moment. Zespół nie chce się z tego za bardzo tłumaczyć, a “nie da się” jest bardzo wygodną wymówką, która jest prawdziwa na ten konkretny czas, bo nie jest to właściwy czas na zmiany. 6. Brakuje umiejętności w zespole, bo nikt nigdy tego nie robił i nie wiedzą, jak coś zrealizować.   7. Brak pozytywnych wzorców, bo w tym zespole czy nawet w całej organizacji, jest bardzo konserwatywne i sztywne nastawienie: “nie da się” wdrożyć nic nowego czy wprowadzić jakichś zmian, bo przecież w przeszłości to nie wyszło”. 8. Negatywne nastawienie jest częścią kultury pracy, w której  w złym tonie jest mieć optymistyczne podejście do wyzwań i problemów. 9. Trudno przebić się przez liderów opinii, którzy narzucają całemu zespołowi swoje zdanie i przekonania. Jest to tym mocniejsze, im większy autorytet mają Ci liderzy. Co zrobić, gdy zespół mówi “nie da się”? 1. Odrzuć pierwsze “nie”, traktując je jako zachętę do rozmowy. Najpierw daj zespołowi przemyśleć propozycję, zadać dodatkowe pytania, przedyskutować różne pomysły. Wówczas ta automatyczna odpowiedź “nie da się”, ma szansę przemienić się w bardziej proaktywną postawę. 2.  Zrozum powody oporu zespołu, zapraszając zespół do głębszej rozmowy o przyczynach takiego nastawienia. Pozwoli Ci to uświadomić sobie istotę sprawy, która być może blokuje zespół, a to będzie podstawą do pracy nad zmniejszeniem tego oporu.  Klasyczną techniką, która tu się sprawdzi, jest przejście przez serię pytań “dlaczego” lub wizualizację tych wszystkich powodów, dla których jest, jak jest. Może się okazać, że od bardzo powierzchownych przyczyn, dojdziecie do tych głęboko zakorzenionych, które można spróbować zmodyfikować.  3. Przeciwstaw się pesymizmowi niektórych osób. Często na nastawienie zespołu ma postawa liderska, zarówno tych liderów formalnych, jak i nieformalnych, za którymi idzie zespół. Negatywnie nastawieni członkowie zespołu, często potrafią ubić jakiś pomysł już w zarodku, a zespół to podchwytuje. W takim przypadku zachęcamy do takiego nawet trochę mniej eleganckiego zachowania i zadziałania za plecami osoby z tym pesymistycznym nastawieniem. Gdy wspólnie już coś zaczniecie działać, to może się okazać, że pojawi się dowód pokazujący, że te proponowane zmiany, działają. 4. Przekonaj przez fakty i dane, wykorzystując do tego różne case study, czy historie z innych firm i zespołów. Możesz też powołać się na jakieś swoje rozwiązania, które być może nie są powszechne w zespole. Porada ta bazuje na założeniu, że w zespole jest jakiś brak wiary czy pewności, że coś się uda, ale możecie nad tym wspólnie pracować. 5. Poszukaj, jak zdobyć wiedzę, gdyż opór może wynikać z jej braku. Zespół nie wie, jak do czegoś podejść, bo nie zna technik, teorii lub narzędzi. Dlatego zachęcamy do poszukiwania sposobów, aby te techniki czy

Co to jest zaawansowany agile i jakie ma odcienie? Tym razem nieco bardziej refleksyjna treść, w której rozważamy o tym, kiedy możemy mówić o dojrzałym podejściu do zwinności oraz jakie wyróżniamy poziomy zaawansowania. Porządny Agile · Zaawansowany agile Do pochylenia się nad tym tematem, skłoniło nas szkolenie 'Advanced Agile’ Alistaira Cockburna, na które się wybieramy. Spis treści Poziomy zaawansowania AgileKiedy możemy mówić o zaawansowanej zwinności?Umiejętność doboru technik do sytuacjiZaawansowanie w prostocie i płynnościZwinność stosowana odruchowoFAQ: Zaawansowany agile📄Transkrypcja podcastu „Zaawansowany agile” Poziomy zaawansowania Agile Wątek ten zaczniemy od podzielenia się dwoma metaforami z życia prywatnego. Pierwsza z nich wiąże się z modelarstwem, a konkretnie modelarstwem plastikowym i tworzeniem replik samolotów z okresu II wojny światowej.  Osoba zupełnie początkująca w modelarstwie zazwyczaj stara się trzymać kurczowo instrukcji albo korzysta z książek będących swoistymi podręcznikami młodego modelarza. W nich znajdzie podstawowe informacje jak przecinać elementy, jak je doklejać czy malować. Dla takiej początkującej osoby najlepszą strategią jest właśnie podążanie za instrukcją.  Po sklejeniu kilku modeli i nabraniu wprawy pojawia się chęć spróbowania czegoś innego. Obserwując innych, widzi, że można zboczyć trochę z trasy wyznaczonej przez instrukcję i dodać coś od siebie, sprawdzić jak dany samolot wyglądał w rzeczywistości i jeszcze bardziej upodobnić model do oryginału. Z kolei osoby mocno zaawansowane często nawet nie zaglądają do instrukcji. Ponadto wiele elementów jest wyrzucana i zamiast nich wykorzystywane są samodzielnie wybrane lub stworzone dodatki. Ostatni poziom stanowią osoby, które tworzą unikalne modele z wykorzystaniem własnych technik. Mogą też budować całe scenki rodzajowe, gdzie przykładowo samolot, który wylądował na lotnisku, jest obsługiwany, ma otwarte luki, wymieniana jest amunicja, podmontowywane bomby. Oczywiście nie każdy modelarz dochodzi do tego ostatniego poziomu, ale jest to pewna progresja umiejętności i pewności w działaniu. Zwykle jednak każdy, kto się wkręci w hobby, przestaje ściśle trzymać się instrukcji i cały czas szuka nowych technik lub też inspiracji, jak dany model skleić, a potem upiększyć. Druga metafora związana jest z bieganiem, czyli popularnym sportem z bardzo niskim progiem wejścia. Niemal każdy może w tym sporcie znaleźć coś dla siebie. Osoby początkujące zwykle szukają jakiegoś prostego planu treningowego, aby wiedzieć, kiedy biegać dłużej, kiedy szybciej i jak ogólnie dobrze wszystko poukładać.  Gdy zaczną się bardziej interesować bieganiem i bardziej wkręcą się w ten sport, to często dopasowują plan treningowy pod własne potrzeby i cele, jakie chcą osiągnąć. Biorą przy tym pod uwagę swoje słabsze strony, aby faktycznie ten plan treningowy uwzględniał wszystkie istotne aspekty. Czasem postanawiają wziąć udział w jakiś zawodach, a kiedy indziej po prostu progresować swoje umiejętności i możliwości.  Osoby najbardziej zaawansowane mają już wszystko szczegółowo i bardzo dobrze rozpisane pod siebie. Często ich plany treningowe są całkowicie inne od tych, z jakich korzysta osoba początkująca. Czasem też łamią pewne zasady i wskazówki dawane początkującym, bo są już świadomi siebie, znają swoje ciało, mają doświadczenie i wiedzą, na co mogą sobie pozwolić. Podobnie jak przy modelarstwie, tak i przy bieganiu, widać, że im jesteśmy bardziej zaawansowani w danej dziedzinie, tym coraz bardziej sobie dopasowujemy pewne rzeczy pod własne potrzeby. Oboje czujemy, że z agile jest bardzo podobnie. Osoby dopiero rozpoczynające przygodę z agile będą pewnie starały się trzymać instrukcji, robić pewne rzeczy rutynowo, nie zastanawiać się i nie wnikać w to, że coś można zrobić lepiej, w bardziej dopasowany do zespołu lub organizacji sposób. No, ale wraz ze zdobywanym doświadczeniem, rozmowami z ludźmi, udziałem w konferencjach, zaczynają oni dostrzegać, co jest niedoskonałe, co warto zmienić, jakie reguły poznane na początku warto złamać lub porzucić. Wzbogacają się w nowe techniki i metryki, znają cel, do którego chcą dążyć, a to wszystko powoduje, że sposób swojej pracy i pracy zespołu jest maksymalnie dostosowany do indywidualnych potrzeb.  Kiedy możemy mówić o zaawansowanej zwinności? O zaawansowanej zwinności możemy mówić przede wszystkim wtedy, gdy mamy świadomość pułapki, jaką jest próba postawienia znaku równości pomiędzy zwinnością a Scrumem. Obserwujemy to często, zarówno przyglądając się rynkowi, jak i w pracy z klientami.  Z jednej strony mocno nas to szokuje, z drugiej jest to bardzo inspirujące. Przykładowo, gdy na spotkaniach społeczności otwieramy wątek dotyczący tego, jak mogłaby wyglądać zwinność bez Scruma, często pojawiają się tzw. ScrumButy, czyli powody, dla których zespoły nie mogą w pełni wykorzystać Scruma do w zespole. Na co dzień widzimy zespoły, które zrezygnowały z jakiegoś

Najlepsze pomysły rodzą się w zespołach, na bazie współpracy i wzajemnej inspiracji. Definiujemy „mądrość zespołu.” Wyjaśniamy też, dlaczego to podejście jest tak istotne w dzisiejszym środowisku biznesowym i jakie korzyści może przynieść zarówno liderom zespołów, jak i każdemu członkowi grupy. Podajemy realne przykłady udanego procesu wzmacniania mądrości zespołu, ale nie zapomnieliśmy również o antywzorcach, które pokażą, co może pójść nie tak, jeśli nie podejdziemy do tego procesu odpowiednio. Dzielimy się też ośmioma cennymi poradami dotyczących warunków, jakie trzeba stworzyć, by czerpanie mądrości z zespołu było efektywne i owocne. Porządny Agile · #112 – Czerpanie z mądrości zespołu Sukces zespołu to nie tylko efektywna realizacja zadań, ale także umiejętne wykorzystanie siły i mądrości, jakie drzemią w jego członkach. Prowadząc warsztaty, niejednokrotnie widzimy, jaki potencjał tkwi w zespołach, jak dobre rozwiązania potrafią wytwarzać, jeśli zapewni się im tylko odpowiednie warunki do pracy.  Spis treści Jak rozumieć mądrość zespołu?Przykład i antyprzykład czerpania mądrości z zespołuJak czerpać z mądrości zespołu?📄Transkrypcja podcastu „Czerpanie z mądrości zespołu” Ten potencjał, tę mądrość zespołu, warto wykorzystywać na różnych etapach pracy, poczynając od wczesnych momentów odkrywania, co jest do zrobienia, poprzez proces tworzenia Backlogu Produktu, planowania pracy, czy realizacji różnych zadań. Można go również sięgnąć do niej w ramach projektów związanych z transformacją, reorganizacją zespołów czy zmian w funkcjonowaniu organizacji. Jak rozumieć mądrość zespołu? Nim przejdziemy do przykładów czerpania z mądrości zespołu oraz naszych porad, jak to dobrze wykorzystać, przytoczymy krótką historię. Kuba, będąc dość młodym menedżerem, został zaproszony do ćwiczenia zespołowego, stanowiącego grę managerską. Uwidacznia ono dobrze mądrość zespołu. Ćwiczenie polegało na tym, że uczestnicy dostali pewną historię związaną z samolotem, który rozbił się gdzieś na zupełnym pustkowiu. Zadaniem grupy było zdefiniowanie, jaki mają pomysł na to, aby przetrwać tę trudną sytuację i jakie narzędzia im w tym pomogą. Już na początku prowadzący zadeklarował, że to, co wymyślimy jako grupa, będzie mądrzejsze, lepsze niż to, co wymyśli dowolny z nich indywidualnie. Powiedział o tym, bo mieli sobie najpierw wypisać własne pomysły, a potem jako grupa ustalić jedno wspólne rozwiązanie. I faktycznie prowadzący miał rację, a Kuba potwierdził to wielokrotnie, przeprowadzając to ćwiczenie w innych kontekstach. Konsekwentnie ciągle wychodzi tak, że grupy są mądrzejsze niż pojedynczy uczestnik w nią wchodzący.  Bazując na tym, możemy powiedzieć, że mądrość zespołu to jest sytuacja, w której suma pomysłów członków zespołu jest lepsza niż pojedyncze pomysły, a nawet lepsza niż najlepszy pomysł pojedynczego członka zespołu. Ważne, aby pamiętać, że bazą takiej mądrości jest faktyczny zespół, a nie tylko losowa grupa ludzi, która została czy posadzona w jednej przestrzeni, czy po prostu określona jako grupa. Ten solidny fundament jest niezbędny, aby mądrość zespołu faktycznie się pojawiła.  Przykład i antyprzykład czerpania mądrości z zespołu Przykład Jacka: prowadząc warsztaty, wspólnie z zespołem odkryliśmy, że można byłoby zdecydowanie lepiej planować pracę. Poprosiłem zespół, żeby w parach przygotowali elementy dobrego planu. Okazało się, że suma tego, co wypracowały poszczególne pary, była naprawdę świetną listą, do której trudno było tak naprawdę dodać coś jeszcze. Tak dobrze ta grupa pokryła wszystkie te elementy, które są konieczne, żeby taki plan się pojawił. Przykład Kuby: mądrość zespołu bardzo często jest widoczna, gdy musi on podzielić elementy Backlogu na mniejsze kawałki. Z kolei antyprzykładem mądrości zespołowej jest sytuacja, gdy Product Owner lub analityk samodzielnie decyduje, że tego już się nie da podzielić. Wówczas zamiast mądrości zespołu, otrzymujemy fałszywą zgodę na to, że skoro ktoś uważa, że czegoś nie da się już podzielić, to znaczy, że wszyscy tak myślimy.  Jeśli jednak stworzymy warunki do tego, aby każdy mógł podzielić się swoim pomysłem, to zespół ma z czego czerpać. Nawet jeśli nie wszystkie sposoby są do zrealizowania lub nie wszystkie zostaną przyjęte, to jednak zazwyczaj poszczególne osoby się wzajemnie inspirują, dyskutują, tworzą wspólnie jeszcze lepsze pomysły. Jak czerpać z mądrości zespołu? Uświadom sobie potencjał zespołu – To porada kierowana do lidera lub jakiegoś rodzaju moderatora zespołu. Być może osoba ta nie ma dobrych doświadczeń związanych z mądrością zespołu lub może nigdy nie pokazano jej, że w zespole jest większy potencjał niż w poszczególnych jednostkach. Stąd też pierwszym krokiem, który radzimy osobie mającej wpływ na to, jak zespół pracuje, jest przemyślenie sobie, czy jej metody postępowania, metody wydawania instrukcji lub ogólnie metody prowadzenia tego zespołu nie powodują, że nie ma za wiele okazji do czerp

Cel Produktu jest elementem, który pojawił się w ostatniej aktualizacji Przewodnika po Scrumie. Nadal spotykamy się z tym, że zespoły nie używają go w codziennej pracy, ani go nie formułują. Przybliżymy Ci ten temat. Wyjaśniamy czym jest Cel Produktu, podajemy przykłady Celu Produktu i wskazówki jak najsensowniej wykorzystać go w codziennej pracy. Porządny Agile · #111 – Cel Produktu Cel Produktu jest istotnym elementem Scruma, a jest on często niedoceniany. Dlaczego jest tak ważny i jak go właściwie wykorzystać, aby osiągnąć sukces w projekcie Scrumowym?  Spis treści Co to jest Cel Produktu?Jak działa Cel Produktu?Jak zastosować Cel Produktu w praktyce?FAQ: Cel ProduktuDodatkowe materiały📄Transkrypcja podcastu „Cel Produktu” W tym artykule podzielimy się z Tobą wskazówkami do definiowania i utrzymywania Celu Produktu, opierając się na praktycznych przykładach. Co to jest Cel Produktu? Cel Produktu definiuje Przewodnik po Scrumie. “Każdy artefakt [Scrumowy – czyli Backlog Produktu, Backlog Sprintu i Przyrost – przyp. red.] wiąże się ze zobowiązaniem, które zapewnia dostępność informacji poprawiających przejrzystość i skupienie, w odniesieniu do których można mierzyć postępy. Zobowiązania istnieją po to, aby wzmocnić empiryzm oraz wartości scrumowe w samym Scrum Teamie, jak i u jego interesariuszy.” Zobowiązania są tworzone, aby uniknąć pracy w chaosie, a jednym z takich zobowiązań jest właśnie Cel Produktu. Opisuje on przyszły stan produktu, a jednocześnie pozwala on się skupić na działaniach prowadzących do powstania przyrostu produktu. Cel produktu ułatwia stworzenie planu działania i jest on odzwierciedlony w Backlogu Produktu. Scrum podkreśla, że ustalony Cel Produktu jest stały, ale pomysł na jego realizację, czyli zawartość Backlogu Produktu, może się zmieniać. Przewodnik po Scrumie mówi jeszcze, że “Cel Produktu to długoterminowe zamierzenie Scrum Teamu. Zespół musi zrealizować jeden cel (lub z niego zrezygnować), zanim przystąpi do realizacji kolejnego.”. Wspomniana powyżej rezygnacja z celu nie dotyczy tylko sytuacji, gdy czegoś nie uda się nam zrealizować. Dotyczy także scenariusza, gdy wspólnie stwierdziliśmy, że osiągnęliśmy poprzedni cel w wystarczającym stopniu i możemy sobie zdefiniować nowy. Pozwala to rozwijać produkt w ukierunkowany i bardziej poukładany sposób. Jak działa Cel Produktu? Wyobraź sobie, że wraz z zespołem zajmujecie się rozwojem platformy ze sklepem internetowym. W ramach tego projektu moglibyśmy ustalić kilka różnych celów na poszczególnych jego etapach: Na bardzo wstępnym etapie projektu, gdy sklep jest dopiero tworzony, Celem Produktu może być uruchomienie pierwszej sprzedaży. Obejmowałoby to stworzenie tego sklepu i wykonanie wszystkiego, co potrzebne, aby można było sprzedawać produktu na tej platformie. W przypadku funkcjonującego już sklepu, który działa tylko na terenie jednego kraju, Celem Produktu mogłoby być zwiększenie zasięgu geograficznego. Oznaczałoby to utworzenie kolejnej wersji językowej sklepu i uruchomienie na nie sprzedaży. Gdy zachodzi potrzeba poprawy wyników biznesowych, za Cel Produktu można obrać optymalizację procesu zakupowego dla klienta. Taki Cel może być mierzony wzrostem konwersji koszyka o 1 punkt procentowy. W momencie zmian legislacyjnych Celem Produktu mogłoby być uzyskanie zgodności z nowymi przepisami w wyznaczonym przez ustawodawcę terminie.  Jeśli platforma sklepowa nie była aktualizowana wiele lat i dług technologiczny jest już duży, Cel Produktu może być bardziej „techniczny”. Może to być na przykład zmigrowanie sklepu na inną platformę nowocześniejszą technologicznie. Przytoczone przez nas cele są oczywiście dość ogólnymi przykładami. Naszym zamysłem było pokazanie, że niezależnie od treści tego celu, zazwyczaj musi być on realizowany przez cały zespół. Zajmie to przynajmniej kilka Sprintów, z których każdy będzie miał swój odrębny Cel Sprintu.  Przyjrzyjmy się teraz dokładniej przykładowemu Celowi, jakim jest wzrost konwersji w koszyku. Załóżmy, że firma korzysta z badań użyteczności, wiedzy eksperckiej i słucha feedbacku od klientów. Product Owner wraz z Zespołem Scrumowym mogą rozłożyć ten Cel Produktu na kilka konkretnych różnych od siebie Celów Sprintu: uproszczenie formularza w pierwszym Sprincie, przyspieszenie wydajności strony w drugim Sprincie, dodanie płatności ratalnej w kolejnym Sprincie,  dodanie mechanizmu prostego powrotu do nieukończonego zakupu w następnym Sprincie. Każdy Sprint ma swój odrębny cel, jednak wszystkie sumarycznie, choć w różny sposób, przybliżają nas do realizacji Celu Produktu. Jak zastosować Cel Produktu w praktyce? 1. Zaczynaj Refinement danego elementu Backlogu produktu od dyskusji o Celu Produktu Pozwoli to upewnić się, że omawiane w procesie Refinementu kwestie są faktycznie zgodne z Celem Produktu. Warto także sprawdzić, czy wszyscy członkowie zespołu go rozumieją i wiedzą, co jako zespół mają osiągnąć. Jest to potrzebne zwłaszcza

Dlaczego warto rozważyć używanie Scruma do organizacji pracy zespołów managerskich? Jak budować takie zespoły? Jak może wyglądać praca w takim zespole? Dzielimy się też naszymi przemyśleniami na temat funkcjonowania zespołów tego typu, które widzieliśmy w praktyce. Porządny Agile · #110 – Scrum w zespole managerskim Na potrzeby tego artykułu przyjęliśmy, że pojęcie “manager”, będzie obejmować różne grupy na szczeblu kierowniczym, takie jak np. zarząd firmy lub konkretnego regionu, team leaderzy i kierownicy niższych szczebli.  Spis treści Po co Scrum w zespole managerskim?Jak wykorzystać Scruma w zespole managerskim?Nasze przemyślenia na temat Scruma w zespole managerskimFAQ: Scrum w zespole managerskim📄Transkrypcja podcastu „Scrum w zespole managerskim” Co ważne, będziemy tu mówić nie o czystym Scrumie, a bardziej o agile i technikach zwinnych zapożyczonych ze Scruma. Chcemy przedstawić Ci jak najszersze spojrzenie na to zagadnienie, gdyż czasem po prostu warto korzystać z różnych praktyk i łączyć je ze sobą. Po co Scrum w zespole managerskim? Przede wszystkim o wdrożeniu technik zwinnych do zespołu managerów warto pomyśleć, gdy widzimy brak współpracy między jego członkami. W wielu organizacjach managerowie funkcjonują bez ścisłej współpracy ze sobą, trochę w takim oderwaniu. Oczywiście czasem widzą się na jakiś spotkaniach, ale często są to po prostu jakieś statusy czy podsumowania, a nie faktyczne współdziałanie. Drugim powodem może być zaobserwowanie, że obecny sposób działania nie rozwiązuje problemów, jakie stoją przed tym zespołem. Wówczas może pojawić się chęć skorzystania z bardziej zdyscyplinowanych form współpracy, aby zoptymalizować sposób ich działania.  Zwłaszcza jeśli zespoły mierzą się z dużymi wyzwaniami, np. istotne zmiany w organizacji, czy jakieś istotne inicjatywy strategiczne. W dużych projektach praca managerów jako osobnych jednostek, bez współdziałania i poczucia, że dążą do wspólnego celu, może być nieskuteczna. Takim szczególnym przypadkiem, w którym warto pochylić się na Scrumem w odniesieniu do managerów, jest kryzys w projekcie lub w danej organizacji. Takie sytuacje zwykle wymagają sprawnego działania, żeby podjąć odpowiednie decyzji i opanować sytuację. Jak wykorzystać Scruma w zespole managerskim? W zależności od projektu członkami Zespołu Scrumowego mogą być managerowie średniego szczebla z głównym przełożonym lub też wyżej postawieni liderzy, a nawet członkowie zarządu. Podobnie jak w zespołach developerskich, tak i tu Zespół Scrumowy powinien zawierać wszystkie niezbędne kompetencje, gromadząc managerów i liderów niezbędnych w organizacji.  Jeśli organizacja ma już doświadczenie w pracy ze Scrumem, to na pewno łatwiej będzie zacząć i posiłkować się posiadaną wiedzą. Jeśli natomiast jest to coś nowego, to warto uzupełnić wiedzę np. warsztatami czy szkoleniami lub zaangażować mentora, który ma już doświadczenie w praktycznym wykorzystywaniu Scruma. Sugerujemy jednak traktować ten framework podejścia zwinnego jako inspirację i nie podchodzić do wszystkiego na sztywno. Jedną z pierwszych decyzji, jakie Zespół Scrumowy musi podjąć to ustalenie długości Sprintu. Najczęściej obserwujemy klasyczne 2 tygodniowe długości Sprintów, czasem tygodniowe, ale jeśli zespół powoływany jest z powodu sytuacji kryzysowej lub w ramach pilnego projektu, to można nawet skrócić ten czas do dwóch czy jednego dnia. W ramach Sprintów tworzone są kolejne wersje rozwiązania, które następnie prezentowane są Interesariuszom. Ci z kolei dzielą się informacją zwrotną.  Ważnym elementem pracy zespołu są Retrospektywy, czyli podsumowanie Sprintu i wymiana spostrzeżeń, rozmowy o tym, jak się pracowało, co można usprawnić lub jaką nową taktykę wprowadzić.  Nasze przemyślenia na temat Scruma w zespole managerskim Podzielimy się teraz z Tobą naszymi przemyśleniami dotyczącymi funkcjonowania zespołów managerskich wykorzystujących Scruma, które widzieliśmy lub które wspieraliśmy. 1. Scrum jako inspiracja i punkt odniesienia Wspominaliśmy o tym na początku artykułu, żeby pozwolić sobie na pewną elastyczność, jeśli chodzi o wdrażanie Scruma do zespołu i trzymanie się reguł. Oczywiście staramy się dostosować jak najbardziej do zasad, ale pamiętajmy, że to często będzie bardzo rewolucyjna zmiana w sposobie pracy osób wchodzących w skład zespołu. Zachęcamy do traktowania Scruma jako framework, bo obserwujemy czasem, że zmianie jedynie ulegają nazwy spotkań, aby brzmiały bardziej Scrumowo, a w praktyce wciąż mają formę statusu, gdzie każdy jest odpytywany z tego co zrobił. Innym przykładem zbyt powierzchownego podejścia do pracy zwinnej jest organizowanie jedynie codziennego Stand-upu. Naszym zdaniem to za mało, aby móc mówić o podejściu zwinnym. 2. Praca “czystym Scrumem” może być zbyt trudna dla członków zespołu Poprzez pracę z “czystym Scrumem” mamy na myśli wdrożenie wszystkich niezbędnych narzędzi, reguł i technik. Bierze się to stąd, że zespoły te mają inną specyfikę,

Spotkania 1 na 1 to okazja do indywidualnej regularnej rozmowy, gdzie jedna osoba spotyka się bezpośrednio z drugą. Mogą być one bardzo wartościowe w kontekście pracy Scrum Mastera i członków zespołu. Kiedy warto stosować taką formułę w swoim zespole? Dowiesz się też jakie sytuacje – naszym zdaniem – mogą być pułapką przy tej formule. Porządny Agile · #109 – 1 na 1 ze Scrum Masterem Pytania o spotkania „jeden-na-jeden” ze Scrum Masterem padają od czasu do czasu w ramach mentoringów, jakie prowadzimy. Postanowiliśmy przyjrzeć się tematowi z bliska i podzielić naszą opinią w tej kwestii.  Spis treści Czym są spotkania 1 na 1?Kiedy spotkania 1 na 1 ze Scrum Masterem mają sens?Kiedy spotkania 1 na 1 mogą być pułapką i jak jej zapobiec?FAQ: 1 na 1 ze Scrum MasteremDodatkowe materiały📄Transkrypcja podcastu „1 na 1 ze Scrum Masterem” Co ważne, nie będziemy poruszać tu samej idei spotkań 1 na 1, w których bierze udział pracownik ze swoim przełożonym. Odniesiemy się wyłącznie do spotkań, podczas których Scrum Master spotyka się w formule one-on-one z Członkami Zespołu Scrumowego. Czym są spotkania 1 na 1? Spotykaliśmy się z różnymi nazwami tego typu spotkań, np. 1:1, one on one, one to one, czy też face to face. Nie mniej bez względu na nazwę, są to regularne spotkania, typowo stosowane w relacji przełożony podwładny. Zazwyczaj jego celem jest feedback i popracowanie nad bieżącym rozwojem kompetencji danej osoby. Może to też być omówienie kwestii bardzo indywidualnych dla danej osoby, które nie nadają się do omawiania w większym gronie. Poruszane tematy mogą również dotyczyć jakiś dyskretnych spraw jak zmiany organizacyjne lub personalne.  Kiedy spotkania 1 na 1 ze Scrum Masterem mają sens? Widzimy 6 sytuacji, w których naszym zdaniem spotkania 1-na-1 Scrum Mastera z Członkiem Zespołu mają sens: Gdy Scrum Master dołącza do nowego Zespołu, to tego typu spotkania mogą być dobrym elementem wzajemnego poznania się. Obie osoby mogą zobaczyć się z tej indywidualnej strony, zbudować relację i  zaufanie. Może to być też seria kilku spotkań, żeby się zrozumieć, porozmawiać o swoich motywacjach, zobaczyć perspektywę różnych osób. Jeśli któraś ze stron wykaże taką potrzebę, mogą zostać ustalone regularne spotkania 1 na 1. Więcej o początkach Scrum Mastera w nowym Zespole rozmawialiśmy w 12. odcinku podcastu. W ramach współpracy Scrum Mastera z Product Ownerem dobrą praktyką jest organizowanie spotkań między nimi, bardziej lub mniej regularnie. Pozwolą one na przygotowanie się do konkretnych wydarzeń Scrumowych czy przedyskutowanie jakichś kwestii technicznych, czy kierunków rozwoju produktu. O współpracy Scrum Mastera i Product Ownera posłuchasz w odcinku 11 podcastu Porządny Agile. W sytuacji, gdy o takie spotkanie prosi sam Członek Zespołu. Być może chce popracować nad czymś, przegadać pewne wątki lub poruszyć tematy relacyjne między nimi. Może to być też np. rozmowa o rozwoju zawodowym. Zwłaszcza jeśli rozmówca jest na pozycji juniorskiej, dla której Scrum Master będzie mentorem, podpowie kierunki pracy. Jest to możliwe zwłaszcza, jeśli SM ma doświadczenie na stanowiskach, które interesują Członka Zespołu. Scrum Master często ma też szerokie kompetencje miękki i może pomóc popracować nad problemami komunikacyjnymi, formułowaniem myśli lub facylitacją spotkań. Aby zrozumieć niejasną sytuację, która pojawiła się w zespole i Scrum Master musi ją poznać lub wyjaśnić. Przykładowo Zespół dziwnie się zachowuje, dzieje się coś, co wzbudza niepokój, a Scrum Master nie wie co jest nie tak. Spotkania 1 na 1 będą dobry sposobem na “spróbkowanie” Członków Zespołu. Może to być dowiedzenie się bezpośrednio od nich, co się wydarzyło. Czasem będzie to zebranie różnych opinii i perspektyw, a następnie zbudowanie sobie pełniejszego i jaśniejszego obrazu sytuacji. W Zespole zaistniał poważny problem i nie ma chęci poruszania go na forum. Są sytuacje, w których pewne kwestie warto przepracować indywidualnie. Może to być jakiś konflikt, uprzedzenia lub jakaś głęboko ukryta kwestia związana z procesem wytwarzania produktu. Gdy Scrum Master przygotowuje nową osobę lub nowe osoby do roli Scrum Mastera w Zespole. Może tak się zdarzyć, gdy przykładowo szykuje swojego następcę, gdyż opuszcza zespół lub zmienia rolę. Przekazywanie wiedzy w relacji jeden na jeden będzie miało formę trochę mentorską, ale i bardziej ośmielającą do zadawania pytań. Kiedy spotkania 1 na 1 mogą być pułapką i jak jej zapobiec? Przyjrzyjmy się teraz sytuacjom i powodom, które mogą sprawić, że spotkania 1 na 1 Scrum Mastera z Członkiem Zespołu niekoniecznie będą odpowiednią formułą. Podzielimy się też pomysłami, jak rozwiązać ewentualne problemy, czy pułapki z tym związane? 1. Poczucie, że Scrum Master to manager zespołu. Jeśli Członek Zespołu w przeszłości praktykował ze swoim menadżerem spotkania w formule 1 na 1, to bardzo łatwo może postawić zbyt szybko znak równości pomiędzy Scrum Masterem a menadżerem. Skoro wcześn

Czym są modele VUCA i BANI? Jak sobie radzić z aspektami, których dotykają VUCA i BANI? Jak firmy wykorzystują modele VUCA i BANI w swoich strukturach i funkcjonowaniu? Poznaj nasze zdanie odnośnie do modeli zarządzania VUCA i BANI. Zaproponowaliśmy też nasze praktyki, które odpowiadają na wizję świata VUCA i BANI. Porządny Agile · #108 – Świat VUCA i BANI Co poruszamy w materiale o VUCA i BANI? Spis treści Świat VUCA i BANI – jak je rozumieć?Jak sobie radzić z aspektami modelu VUCA? Jak sobie radzić z aspektami modelu BANI? Podsumowanie materiału na temat VUCA i BANIFAQ: Świat VUCA i BANI📄Transkrypcja podcastu „Świat VUCA i BANI” Świat VUCA i BANI – jak je rozumieć? Nazwy obu modeli – VUCA i BANI – rozwijają się do konkretnych słów, które je precyzyjnie opisują. Poniżej znajdziesz opis obu modeli VUCA i BANI wraz z przykładami. Świat VUCA VUCA to skrót od: Volatility (zmienność) Uncertainty (niepewność) Complexity (złożoność) Ambiguity (niejednoznaczność) Model ten wytłumaczymy na przykładzie pandemii, która w 2020 wywołała spore zamieszanie na całym świecie. Pandemia wniosła dużo zmienności w wielu obszarach naszego życia. Ciągłe restrykcje, ograniczenia, nowa wiedza o wirusie. Wszystko to spowodowało, że musieliśmy w jakiś sposób zaadaptować się do tej zmienności. Dodatkowo pojawiła się niepewność, która towarzyszyła każdemu z nas. Wystarczy przypomnieć sobie początki pandemii, kiedy to trudno było ocenić, jak się konkretnie rozwinie, ile będzie trwała. Kto ma rację w dyskusjach i jak się uchronić przed zachorowaniem. Pojawiały się różne opinie w społeczeństwie, komunikaty ze strony rządu oraz wypowiedzi lekarzy i ekspertów, którzy nierzadko mieli odmienne porady i przekonania.  Dużym wyzwaniem była także spora złożoność. Pandemia dotknęła niemal każdej dziedziny życia i trudno było podejmować decyzje, co do których będziemy mieć pewność, że będą dobre. Momentami było to raczej eksperymentowanie i ocenianie, jakie przyniesie to skutki. W tym wszystkim panowała spora niejednoznaczność. Z zewsząd pojawiały się sprzeczne informacje. Nie wiadomo było, na których danych oprzeć swoje działanie. Pojawiały się pytania związane ze strategią walki z wirusem. Nie wiedzieliśmy, czy lepszy jest lockdown, czy może budowanie zbiorowej odporności, jak to odbywało się w niektórych państwach.  Świat BANI BANI to skrót od:  Brittle (kruchy),  Anxious (niespokojny),  Non-linear (nieliniowy),  Incomprehensible (niezrozumiały). Koncepcja BANI mocno rozpowszechniła się w ciągu kilku ostatnich lat. Jest naszym zdaniem mniej optymistyczna i bardziej ponura niż VUCA. Kruchość Kruchość oznacza złudne poczucie siły i odporności. Przekonanie to funkcjonuje w wielu organizacjach, które uważają, że są w stanie zaplanować przyszłość i nad wszystkim zapanować. Natomiast szereg różnego typu kryzysów mocno testuje to założenie. Przykładowo w czasie pandemii Covid-19 wiele organizacji ucierpiało przez przerwanie łańcuchów logistycznych. Napaść Rosji na Ukrainę również pokazuje nieoczywiste na pierwszy rzut oka zależności biznesów od zjawisk, które są poza ich kontrolą. Niepokój Szereg kryzysów politycznych, gospodarczych czy klimatycznych wiąże się też z niepokojami społecznymi, które odbijają się na organizacjach w kontekście czysto ludzkim. Pracownicy są ponadprzeciętnie zestresowani i głowy mają zaprzątnięte masą innych tematów niż tymi związanymi z pracą zawodową. Nieliniowość Kolejny element skrótu BANI to nieliniowość. Koncepcja nieliniowości mówi o tym, że zjawiska opisujące wzory na funkcjonowanie firm, np. zyskowność firmy czy sukces na rynku, niekoniecznie mają funkcję liniową. Innymi słowy, nie jest tak, że możemy mieć pewność co do tego, że zwiększenie aktywności sprzedażowej da nam więcej zysku. Stąd też wiele organizacji złudnie polega na tym, że może wiele rzeczy przewidzieć, prognozować lub spokojnie zaplanować.  Nieliniowość pokazuje nam, że nawet jeśli długo stan jakiegoś zjawiska jest stabilny, to istnieje trudny do przewidzenia próg, kiedy wszystko się zmieni. Zmiana ta może być pozytywna lub negatywna. Przykładowo jeden kontrakt więcej, jedno usprawnienie produktu i biznes mocno rusza w rozwoju. I w drugą stronę – jedna sprzedaż mniej, jeden niezadowolony klient więcej i wszystkie wyniki się nagle załamują. Organizacja może nie mieć pojęcia, z czego tak nagłe tąpnięcie wyniknęło. Niezrozumienie BANI mówi też, że świat jest niezrozumiały. W danej chwili nie rozumiemy w pełni natury zjawisk. Ponownie dobrym przykładem jest pandemia, kiedy to nikt nie wiedział, w jakim kierunku wszystko się rozwinie. W realiach organizacji wiąże się to z niepewnością, trudnością podejmowania decyzji i działania. Zwłaszcza osoby zarządzające nie rozumieją, z czego różne zjawiska wynikają i nie wiedzą, jak się rozwiną. Jak sobie radzić z aspektami modelu VUCA?  V – Volatility – Jak sobie radzić ze zmiennością? Przede wszystkim zaak

Zespoły często pracują projektowo poprzez formułowanie precyzyjnych zakresów prac. Chcemy Ci pokazać i zainspirować do innego sposobu pracy jakim jest praca na celach. Formułowanie celów nie jest takie łatwe i proste, jak mówi o tym teoria. Wyszczególnimy najpopularniejsze trudności pracy z celami i podamy konsekwencje, które się z nimi wiążą. Podajemy też nasze rekomendowane rozwiązania na wspomniane trudności. Porządny Agile · #107 – Trudności z pracą na celach Jakie trudności z pracą na celach napotykają zespoły? Sprawdź naszą subiektywną listę najczęstszych problemów z celami w zespołach zwinnych, zawartą w spisie treści poniżej: Spis treści Natłok celówRóżne cele dla różnych zespołówCel niezrozumiały przez odbiorcówNieosiągalny cel Balans między terminem, jakością i budżetemFAQ: Trudności z pracą na celach📄Transkrypcja podcastu „Trudności z pracą na celach” Oprócz opisu problemu, do każdej kwestii proponujemy także po dwa rozwiązania, jakie widzimy. Natłok celów Trudność ta pojawia się w sytuacji, gdy zespół lub zarządzający nie mają możliwości lub umiejętności ustalenia priorytetów i podjęcia decyzji, na czym się skupić w danym momencie. Dodatkowo sytuację może tu pogorszyć, gdy próbuje się zrealizować pomysły z różnych, często sprzecznych względem siebie obszarów.  Konsekwencją natłoku celów jest konieczność decydowania, co jest ważne w trakcie prac, a to zaburza działanie zespołu i utrudnia skupienie. To z kolei może pociągać za sobą ryzyko, że cele nie zostaną zrealizowane lub rezultat będzie mało satysfakcjonujący.  Potencjalne rozwiązania, jakie tu widzimy to: Redukcja ilości i wielkości celów – przede wszystkim Zespół powinien spróbować zawęzić cele do jednego obszaru. A jeśli nie będzie to możliwe, to chociaż zmniejszyć liczby celów, jakie są ustalone do realizacji jednocześnie. W praktyce najczęściej za takie decyzje odpowiada Product Owner. Dzięki temu zespół będzie wiedział, w jakim kierunku zmierza i na czym się skupić w danym momencie. Skrócenie horyzontu czasowego, na jaki wyznaczane są cele. Zmusi to Zespół i interesariuszy do zastanowienia się, które cele faktycznie chcą teraz zrealizować, ponieważ planowany jest krótszy okres na ich wykonanie. Tylko kwestie naprawdę najistotniejsze mogą być zrealizowane w pierwszej kolejności, pozostałe czekają „w kolejce”. Różne cele dla różnych zespołów Trudność ujawnia się w sytuacji, w której zespoły, zamiast sprawnie współpracować ze sobą i dążyć do wspólnego celu, są skupione na realizacji swoich własnych celów. Nie mają przestrzeni na wsparcie innych. Przykładem takiej sytuacji może być zespół developerski, który ma swoje indywidualne cele techniczne związane z tym, czym się zajmuje IT. Automatycznie oznaczać to może, że ich cele nie są związane z celami tzw. „biznesu”. To powoduje, że oba zespoły mogą działać w kierunku maksymalizacji własnych celów i skupiać się głównie na swoim obszarze. Główną konsekwencją takiego przypadku jest to, że pewne cele mogą nie zostać osiągnięte. Może to też prowadzić do braku satysfakcji z pracy, konfliktów i eskalacji. W najgorszym obrocie spraw może dojść do bardzo niebezpiecznych nieporozumień pomiędzy częściami organizacji, które teoretycznie powinny ze sobą ściśle współdziałać. Trwały rozdźwięk między celami może w przyszłości mocno utrudnić realizację kolejnych projektów przechodzących wskroś całej organizacji.  Potencjalne rozwiązania, jakie dostrzegamy w tej sytuacji to: Spróbować dogadać się w gronie menedżerów na wyższym szczeblu, zanim ustalone cele będą komunikowane w zespołach. Dzięki temu możliwe będzie uniknięcie sytuacji, w której zespoły albo poszczególni specjaliści mają sprzeczne cele. Być może nie będą one jeszcze wspólne, ale przynajmniej nie będą sprzeczne. Znalezienie wspólnych celów. Pomoże w tym ustalenie priorytetów organizacji jako całości. Warto spojrzeć na strategię i to z niej wybrać cele spójne z kierunkiem rozwoju produktu czy firmy. Cel niezrozumiały przez odbiorców Istotą tej trudności jest to, że członkowie zespołu, których dany cel dotyczy, nie rozumieją go. Nie jest dla nich w pełni jasna konstrukcja celu, jego sens, czy oczekiwane efekty. Dostrzec to można wtedy, gdy losowo wybrana osoba z zespołu nie potrafi powiedzieć własnymi słowami, czemu dany cel jest ważny. Nie umie wyjaśnić jaka logika stoi za wyborem tej kwestii jako priorytetu prac. Trudności ze zrozumieniem celu mogą sprawić, że różne osoby będą inaczej interpretować cel i współpraca będzie utrudniona. Częstą konsekwencją powyższego zjawiska jest brak motywacji wewnątrz zespołów. Pracownicy nie będą szukać kreatywnych rozwiązań produktowych lub sposobów na optymalizację swoich działań.  Jakie rekomendujemy rozwiązania? Upewnienie się, że cel jest zrozumiały dla wszystkich zaangażowanych w jego realizację. Możesz to osiągnąć poprzez aktywne pytanie o feedback dotyczący np. formuły celu, czy rozmowy 1:1. Pomocne też będzie organizowanie sesji p

Jak może wyglądać dalsza ścieżka kariery Scrum Mastera? Agile Coach, Agile Lead, manager zespołu, Product Owner, a może konsultant zewnętrzny? Zdefiniowaliśmy każdą z tych ról i wyjaśniamy, co trzeba rozwinąć, żeby przygotować się do pracy w danej ścieżce. Porządny Agile · #106 – Ścieżki dalszego rozwoju Scrum Mastera W jakim kierunku rozwijać swoją drogę zawodową uwzględniając predyspozycje i umiejętności, jakie posiadamy? Wielu doświadczonych Scrum Masterów i Scrum Masterek, z którymi rozmawiamy, zastanawia się, jak dalej mają pokierować swoją ścieżką zawodową. Rozpatrzmy zatem 6 możliwych opcji, które naszym zdaniem są dobrym wyborem. Spis treści Starszy Scrum MasterAgile CoachAgile Lead – Head of AgileManager zespołuProduct OwnerKonsultant zewnętrznyNasze przemyślenia o ścieżce karieryFAQ: Ścieżki dalszego rozwoju Scrum Mastera📄Transkrypcja podcastu „Ścieżki dalszego rozwoju Scrum Mastera” 6 ścieżek dalszego rozwoju Scrum Mastera to: Starszy Scrum Master, Agile Coach, Agile Lead, manager zespołu, Product Owner konsultant zewnętrzny. Temat ten jest bardzo szeroki i dlatego pokusiliśmy się na trochę uogólnień. Jak wszędzie, tak i w tym zagadnieniu jest wiele wyjątków od reguły. Znamy osoby, które wyłamały się poza schemat i osiągnęły sukces w sposób przeciwny do tego, który omawiamy w tym artykule.  Starszy Scrum Master Starszy Scrum Master to osoba, która ma wiele lat doświadczenia i pracowała z wieloma zespołami. Najprawdopodobniej miała okazja widzieć działanie Scrum w kilku różnych firmach. Dalej pełni swoją funkcję, ale wyróżnia się spośród innych Scrum Masterów. Od “zwykłego” Scrum Mastera różni się tym, że: Dostaje najtrudniejsze przypadki i najważniejsze dla organizacji projekty. Mogą to być m.in. zadania najbardziej problematyczne albo dotyczące skalowania organizacji. Jest mentorem dla pozostałych Scrum Masterów. Oczekuje się od niego, że pewną uwagę będzie poświęcał na wspieranie i dawanie feedbacku mniej doświadczonym osobom w tej roli.  Animuje współpracę w ramach grupy Scrum Masterów i inicjuje akcje międzyzespołowe. Co istotne w rolę tę będzie wchodził z uwagi na swoje doświadczenie i autorytet, a nie z nadania strukturalnego. Jak rozwinąć się do roli starszego Scrum Mastera? Znajomość istoty Scruma – starszy Scrum Master nie cytuje ślepo Scrum Guide’a. Zapytany o powody swoich argumentacji nie argumentuje wszystkiego tym, że „tak jest napisane w Przewodniku po Scrumie”. Osoba ta rozumie, z czego wynikają konkretne wytyczne i praktyki, kiedy je stosować, jak ewoluują i dlaczego istnieją. Co więcej, potrafi to wyjaśnić, także początkującym Scrum Masterom, jak i osobom, które nie pracują w metodykach zwinnych.  Doświadczenie w pracy z kilkoma różnymi zespołami – dzięki temu ma doświadczenie z różnymi kontekstami pracy, osobami i produktami. Każda firma cechuje się swoją specyfiką, ma inną naturę, więc inaczej pracuje się nad jej zmianą.  Działanie w organizacji, która umożliwia rozwój. Nie wszystkie organizacje umożliwiają rozwój w takiej intensywności jak potrzebna i może się okazać, że trzeba zmienić firmę. Tylko w ten sposób będziesz mieć do czynienia z trudnymi sytuacjami, z większą dynamiką pracy, działaniem z różnymi zespołami.  Agile Coach Agile Coach to osoba, która pracuje nad zwinnością organizacji. Wspiera wiele zespołów, a nawet transformację całej firmy. Poza Scrumem pracuje także z takimi metodykami jak np. Kanban, Lean Software Development (LSD), Management 3.0, Design Sprint, czy różne metody skalowania typu LeSS, Nexus, czy SAFe. Agile Coach różni się od Scrum Mastera tym, że: Operuje na wyższym poziomie organizacji. Scrum Master zazwyczaj pracuje z zespołami, a praca z organizacją jest pośrednia, poprzez dbanie o efektywność tych pierwszych. Z kolei Agile Coach bardzo często działa na poziomie całości: całego procesu, zasad działania, czy struktury organizacyjnej. Działa z osobami z managementu o różnych doświadczeniach, często mniej działających w projektach i nad wytwarzaniem oprogramowania, więc Agile Coach powinien mieć wysokie umiejętności interpersonalne, w tym negocjacyjne.  Radzi sobie z większą różnorodnością zadań. Może wspierać organizacje punktowo, poprzez szkolenia, reagowanie na sytuacje kryzysowe, czy przeprowadzanie konkretnych pojedynczych warsztatów. Może też działać na zasadzie obserwacji i odkrywania pewnych sytuacji, na które musi reagować. Mogą to też być zadania proponowane mu przez środowisko, czy też managerów lub bezpośredniego przełożonego. Dlatego też praca Agile Coacha jest o wiele mniej zaplanowana i ustabilizowana. Jest tu o wiele więcej zmienności niż w porównaniu do pracy klasycznego Scrum Mastera.  Tylko okazjonalnie pracuje z jednym zespołem. Agile Coach pracuje zazwyczaj z kilkoma zespołami równocześnie. Może zdarzyć się, że nie pracuje w ogóle z żadnym zespołem, bo zajmuje się tematem ogólnofirmowym. Taki temat (np. podejście do Backlogów Produktu) jest wa

Czy jest sens łączyć podejście zwinne i tradycyjne kaskadowe (tzw. waterfall)? Wskazujemy dziewięć cech odróżniających agile i waterfall. Pokazujemy potencjalne korzyści, jak i zagrożenia wynikające z łączenia tych dwóch sposobów pracy.  Porządny Agile · #105 – Agile i waterfall – łączyć czy nie? Wątek ten wypłynął podczas jednej z naszych rozmów z klientem i postanowiliśmy podzielić się naszymi przemyśleniami. Rozważamy o perspektywie łączenia obu podejść, poprzez dodanie zwinności do istniejącego w organizacji działania w sposób kaskadowy. Spis treści Agile i waterfall – jakie są różnice między nimi?Czy łączenie agile i waterfall ma sens?Dlaczego nie łączyć agile i waterfalla?Kiedy łączyć agile i waterfall?Przestrogi przy łączeniu agile i waterfall’aFAQ: Agile i waterfall – łączyć czy nie?📄TRANSKRYPCJA „Agile i waterfall – łączyć czy nie?” Poniżej celowo prezentujemy dosyć spolaryzowane podejścia . Chcemy wyostrzyć różnice między tymi modelami, bez odnoszenia się do źle wdrożonych podejść. Ten materiał nie jest ani o źle prowadzonej zwinności ani o toksycznej pracy kaskadowej. Agile i waterfall – jakie są różnice między nimi? Różnice w obu podejściach można ująć w 9 wymiarach: 1. Moment definiowania ostatecznego kształtu rozwiązania Podczas pracy w sposób zwinny, produkt powstaje stopniowo, pomysł na docelowe rozwiązanie wyłania się wraz z postępem czasu. Natomiast w podejściu waterfallowym zazwyczaj precyzyjnie definiuje się produkt (wraz z zakresem prac) już na samym początku działań. 2. Moment dostarczenia wartości W dobrze realizowanym podejściu zwinnym wartość dostarczana jest w sposób ciągły, przez cały czas trwania danej inicjatywy. Z kolei w waterfallu bardzo często wartość pojawia się pod koniec lub na faktycznym końcu inicjatywy. 3. Kontakt z użytkownikiem Zwinność cechuje się tym, że dba się o bliski i częsty kontakt z użytkownikiem produktu. Z kolei w waterfallu zespół nie ma zazwyczaj bezpośredniego kontaktu z użytkownikiem, a kontakt ten odbywa się przez pośredników.  4. Nastawienie do zmiany Agile wprost zakłada, że zmiany są dobre i trzeba wykorzystać okazję do ulepszenia produktu i procesu. W klasycznym podejściu zmiany zazwyczaj nie są mile widziane. Dużo energii poświęca się początkowo, aby dobrze określić zakres i zaplanować pracę, aby ewentualnej zmiany można było uniknąć. Dba się też mocno o sformalizowane podejście do zarządzania zmianą w projekcie, co w praktyce zniechęca do prób ich wprowadzania. 5. Interakcje w zespole Zwinność skupia się na zespole, jest on w centrum i interakcje między osobami zaangażowanymi w inicjatywę są ważne. Waterfall koncentruje się na procedurach i procesach, zakładając, że poukładane i sformalne praktyki podnoszą szansę sukcesu i obniżają ryzyka związane z zależnościami pomiędzy członkami zespołu.  6. Odpowiedzialność za końcowy sukces W agile to cały zespół odpowiada za finalny rezultat prac. Z kolei w podejściu kaskadowym pracę rozdziela się pomiędzy różne osoby i to im przydziela się odpowiedzialność za dany wycinek pracy. Najczęściej powołuje się też pojedynczą osobę albo wąskie grono zarządzające całością przedsięwzięcia i to w tych osobach szuka się realnej odpowiedzialności za efekt. 7. Rola managera zespołu W agile manager kreuje środowisko pracy dla zespołu, aby miał on warunki do sprawnego dostarczania wartości. W waterfallu natomiast rolą managera bywa (w zależności od zasad zarządzania w danej firmie): planowanie i rozdzielanie zadań koordynowanie pracy pomiędzy osobami lub zespołami rozliczanie wykonania zadań i ich jakości weryfikacja standardów i zgodności z procedurami. 8. Integracja składowych produktu Zwinność zakłada jak najczęstsze integrowanie małych kawałków pracy, aby jak najczęściej uzyskiwać kolejne wersje działającego produktu. W podejściu kaskadowym integracja zwykle odbywa się na końcu działań, blisko wdrożenia ostatniej wersji rozwiązania. 9. Usprawnienia W agile doskonalenie odbywa się w trybie ciągłym i przebiega w trakcie prac (np. na koniec każdej iteracji). Klasyczny model kaskadowy zazwyczaj usprawnienia przewiduje w postaci jednorazowej sesji lessons learned na koniec projektu.  Czy łączenie agile i waterfall ma sens? Pokazaliśmy powyżej cechy odróżniające oba podejścia – agile i waterfall – od siebie. Czy zatem jest sens je łączyć w ramach jednej organizacji lub nawet pojedynczego projektu? Obaj mamy doświadczenie w pracy w podejściu waterfall i przez pewien czas byliśmy jego zwolennikami. Gdy poznaliśmy agile, zmieniliśmy swoje podejście, zdecydowanie odrzucając kaskadowość. Wraz z doświadczeniem zaczęliśmy dostrzegać jednak sens łączenia obu modeli. Łączenie to zawsze zależy mocno od kontekstu i sytuacji danej organizacji.  Głównym powodem do łączenia modeli jest transformacja zwinna, gdzie etap współegzystowania agile i waterfall traktujemy jako coś przejściowego. Może to być niewygodna ale nieunikniona faza ewolucji danej

Zależności zewnętrzne potrafią zakłócić pracę niejednego zespołu. Tłumaczymy, czym są i wskazujemy 9 sposobów jak sobie z nimi radzić. Porządny Agile · #104 – Zależności zewnętrzne w zespole Jak obsługiwać zależności zewnętrzne i jak sobie z nimi radzić, żeby zwiększyć szanse na realizowanie zaplanowanych elementów? Skąd się one biorą i czy powinniśmy je usuwać? Temat ten wybrzmiał podczas jednej Retrospektywy w zespole, który odwiedzał Jacek. Pomyśleliśmy, że może to być ciekawy temat do podzielenia się z Tobą naszą perspektywą i praktycznymi wskazówkami.   Spis treści Czym są zależności zewnętrzne?9 sposobów na radzenie sobie z zależnościami zewnętrznymi w zespoleFAQ: Zależności zewnętrzne w zespole📄TRANSKRYPCJA „Zależności zewnętrzne w zespole” Zaczniemy od zdefiniowania zależności zewnętrznych i podamy kilka przykładów, potem powiemy sobie, dlaczego powinniśmy usuwać zależności. Na koniec omówimy 9 sposobów na radzenie sobie z zależnościami, jeśli nie możemy ich usuwać. Czym są zależności zewnętrzne? Zależności zewnętrzne to wszystkie działania, które Zespół powinien wykonać, aby zakończyć zaplanowaną pracę na Sprint, ale nie jest w stanie. Dzieje się tak, ponieważ nie ma odpowiednich kompetencji w zespole, by to zrobić. Mogą to być zarówno kompetencje wewnątrz firmowe, jak i takie, które leżą poza naszą organizacją.  Niestety często spotykamy się z mało optymalnym zarządzaniem takimi zależnościami. Członek zespołu zgłasza się do kogoś poprzez email lub system ticketowy i biernie czeka, aż ta druga strona odpowie. To często zawodzi, wydłuża pracę i powoduje tylko problemy. Przykładem zależności zewnętrznej może być współpraca dwóch zespołów. Jeden realizuje rozwiązanie techniczne widoczne na frontendzie, a drugi dostarcza mu API, albo dane, na których ten pierwszy będzie budował. Praca obu zespołów jest od siebie uzależniona.  Innym przykładem zależności, popularnej w dużych strukturach organizacyjnych lub produktach, jest bazowanie przez wiele zespołów na platformach czy usługach. Są to efekty zcentralizowanej pracy zespołów dostarczających rozwiązania infrastrukturalne lub platformowe. Pojedyncze zmiany nie są w możliwościach decyzyjnych czy wykonawczych danego zespołu i musi on czekać na realizację zlecenia.  Zależności często są związane z jakimiś zespołami biznesowymi np. z zespołem prawników czy zespołem marketingu. Przykładem może być sytuacja, w której, aby stworzyć produkt jako całość, musimy polegać na decyzjach, pozwoleniach czy półproduktach prawników. Zespół musi integrować rozwiązanie dostarczone z innych działów z tym, co sam tworzy.  Zależności zewnętrzne są powodem wielu komplikacji, więc co do zasady jesteśmy za tym, żeby takie zależności w miarę możliwości usuwać. Tymi komplikacjami są: czas, czyli wydłużenie czasochłonności realizacji całego zlecenia czy funkcji; potencjalne niezrozumienie wymagań; opóźnienia, jeśli zobowiązania albo standardy procesu nie są dotrzymane; nieporozumienia, wynikające z rozproszenia odpowiedzialności; brak odpowiednich informacji, jeśli praca jest podzielona na wielu wykonawców; konieczność dopasowywania się do różnych metodyk pracy, jeśli zespoły zależne pracują różnie od siebie.  9 sposobów na radzenie sobie z zależnościami zewnętrznymi w zespole 1. Poczekaj na dostarczenie zależności Nie zakładaj optymistycznie, że otrzymasz wszystko, czego potrzebujesz na czas od zespołu, firmy czy osoby z zewnątrz. Zamiast tego ustalcie w Zespole, że nie rozpoczniecie swoich prac, dopóki nie otrzymacie wszystkich potrzebnych elementów czy informacji. Zahaczamy tu trochę o koncepcję Definition of Ready, gdzie przykładowo póki nie dostaniemy interfejsów zewnętrznych, to nie nadbudowujemy na nich swojego działania. Podobnie jest zresztą w leanowym wytwarzaniu produktów, np. w fabrykach samochodów, gdzie prace rozpoczynają się, gdy są wszystkie jego elementy składowe, aby nie zatrzymać pracy fabryki. Takie podejście zmniejsza ryzyko, że praca stanie w miejscu, bo będziemy musieli czekać lub będziemy zmuszeni do przełączania się między różnymi kontekstami, co nie wpływa dobrze na produktywność i ogólnie na pracę.  2. Rozszerz tymczasowo zespół o osobę z zewnątrz Innymi słowy, uzupełniamy zespół o potrzebne kompetencje, których u nas brakuje. Kluczowe jest tu zadbanie o to, aby taka osoba z zewnątrz poczuła się naprawdę częścią zespołu. Dlatego dobrze, aby uczestniczyła w wydarzeniach Scrumowych i była na bieżąco z postępami prac.  Przy tym podejściu możemy dodatkowo zyskać nową wiedzę, którą wykorzystamy w przyszłości i nie będziemy musieli już szukać pomocy na zewnątrz. 3. Zwiększaj kompetencje w zespole Dzięki temu będziemy mogli wyeliminować albo zmniejszyć zależności zewnętrzne. Jest to raczej działanie długofalowe, jednak na koniec może przynieść dużo korzyści.Jednocześnie przesuwamy też granice odpowiedzialności naszego zespołu, np. jeśli do tej pory byliśmy tylko czystym zespołem wytwórczym, to za jak

Scrum Master dosyć często musi mierzyć się z hejtem skierowanym w swoją stronę. Wyjaśniamy, jaka może być przyczyna takich zachowań. Podpowiadamy, co możesz zrobić, żeby nie wpaść w pułapkę hejtowanych Scrum Masterów. Otwarcie mówimy o trudach tej funkcji w organizacji. Porządny Agile · #103 – Hejt na Scrum Masterów Podzielimy się z Tobą naszymi przemyśleniami odnośnie do ostatnich informacji o zwalnianiu całych zespołów Scrum Masterów oraz pojawiającej się w stosunku do nich niechęci. Zastanowimy się, skąd może się brać widoczny w mediach społecznościowych hejt i jak się przed nim możesz uchronić. Spis treści Z czego może wynikać hejt na Scrum Masterów? Jak uniknąć hejtu jako Scrum Master/ka?Dlaczego Scrum Master to twardy kawałek chleba?FAQ: Hejt na Scrum Masterów📄Transkrypcja podcastu „Hejt na Scrum Masterów” Nie jest to dla nas prosty temat i wywołuje dużo trudnych emocji, jednak będziemy się starać być profesjonalni najbardziej, jak to możliwe i konstruktywnie podejść do całej sprawy. Z czego może wynikać hejt na Scrum Masterów?  Oczywiście to wszystko, z czym się teraz z Tobą podzielimy, to w jakimś stopniu nasze domysły i spekulacje. Pierwsze, co nam się nasuwa na myśl i co też przebija się przez komentarze osób, które dyskredytują pracę Scrum Masterów to to, że w danej organizacji lub w danym projekcie czy zespole może w ogóle nie powinno być Scruma. Z kolei Scrum Master obrywa przy okazji i tylko za to, że istnieje i próbuje coś robić, wprowadzać Scruma i tym samym wykonywać swoją pracę. Trochę o tym mówiliśmy w odcinku podcastu pt. Kiedy Scrum nie jest odpowiedzią. Innym powodem, przez który wylewa się hejt na Scrum Masterów, może być sytuacja, że oczekuje się od nich przeprowadzenia zmiany w zespole czy w organizacji. Niestety nikt ich w tym procesie nie wspiera, co może prowadzić do wszelkiego rodzaju wypaczeń lub błędów. W konsekwencji, próbując wdrożyć te zmiany samodzielnie, bardzo często albo im nie wychodzi, albo wszystko ciągnie się bardzo długo. W dodatku mogą pojawiać się zależności, ​​na które Scrum Masterzy nie do końca maja wpływ i ostatecznie nie widzimy żadnych efektów ich działań. Trzecim powodem może być sprzeczność priorytetów w organizacji. Przykładowo tworzy się rolę Scrum Mastera i oczekuje się od niego skupienia na zespole, wprowadzenia zwinności w zespołach i realizacji wartości scrumowych. Natomiast reszta organizacji ma inne priorytety i jest np. sfokusowana na realizację projektu na czas. Scrum Master dba o zespołowość i dobrostan zespołu, a cała reszta organizacji, w tym także management czy Product Ownerzy, będą nastawieni na zupełnie inne rezultaty. To może w efekcie prowadzić do konfliktu. Pracownicy mogą mieć poczucie, że Scrum Master jest odklejony, nie czuje tego, co wszyscy, jako jedyny chce działać inaczej i może wręcz szkodzić ich celowi.  Nieprzychylny stosunek do tej roli może też wynikać z czynników bardziej ludzkich, a konkretniej z postawy Scrum Mastera. Jako pierwsze wysuwa się nam brak pokory będąca pochodną nadinterpretacji słowa “Master” w nazwie tego stanowiska. Może się pojawić poczucie wyższości, bycia mądrzejszym i posiadania jakiejś władzy umożliwiającej mówienie innym, co mają robić. To zapewne nie będzie się podobać reszcie zespołu, zwłaszcza doświadczonym deweloperom z dużą wiedzą i lepszą znajomością produktu od samego Scrum Mastera. Zresztą wywyższająca się postawa mało kiedy jest dobrze odbierana. Brak pokory to jedno, drugie to niefachowe zachowania Scrum Masterów, czyli np. niejasne przedstawianie instrukcji, wybieranie praktyk czy ćwiczeń nieadekwatnie do zespołów i wdrażanie ich na siłę pomimo braku ich zrozumienia, a po czasie nawet chęci ze strony zespołu. Scrum Master może zacząć tracić autorytet i ta rola zaczyna źle się kojarzyć. Ostatnim powodem hejtu na Scrum Masterów, jaki przychodzi nam do głowy, może być to, że czasem faktycznie Scrum Master nie dostarcza żadnej wartości. Zespół nie ma poczucia, że rozwiązuje jakiekolwiek jego problemy, wprowadza usprawnienia, powoduje, że zespół działa wydajniej. Postawa Scrum Mastera jest bardziej pasywna niż aktywna. Może to wynikać z braku umiejętności albo niezrozumienia swojej roli i odpowiedzialności z niej wynikającej. Jak uniknąć hejtu jako Scrum Master/ka? Poniżej podamy 9 wskazówek, ale nie jest to skończona lista. Wybraliśmy te, które naszym zdaniem warto rozważyć w pierwszej kolejności. 1. Zakontraktuj się z zespołem To absolutne BHP pracy z zespołem. Oczywiście zrób to, jeśli wcześniej tego nie zrobiliście. Wspominamy o tym w pierwszym punkcie, bo obserwujemy często relacje Scrum Masterów z Product Ownerem czy deweloperami, gdzie nie zostały przedyskutowane takie podstawowe kwestie współpracy, jak: kto, za co odpowiada, jakie mamy oczekiwania do pozostałych członków zespołu, z czym można przyjść do mnie jako do Scrum Mastera. Brak takich ustaleń powoduje dużo niejasności i niezrozumienia, a co gorsza może prowadzić do napiętej atmosfery, bo poprzed

Nie zawsze trzeba wyceniać błędy. Należymy do tej grupy zwinnych praktyków, która ich nie wycenia. Poznaj nasze argumenty, które nas do tego przekonały. Dowiesz się też jak poradzić sobie z błędami w zespole bez ich wyceniania. Dodatkowo wymieniamy nasze kontrargumenty na najczęstsze powody wyceniania błędów. Porządny Agile · #102 – Dlaczego nie estymujemy błędów? Czy błędy powinniśmy błędy wyceniać, aby pracować zwinne? Jeśli nie – dlaczego nie estymujemy błędów i jak wtedy poradzić sobie z tematem planowania pracy? Spis treści Dlaczego my nie estymujemy błędów?Argumenty zwolenników estymacji błędówJak postępować z błędami?FAQ: Dlaczego nie estymujemy błędów?📄Transkrypcja podcastu „Dlaczego my nie estymujemy błędów?” Pytanie to pojawiło się ostatnio kilkukrotnie podczas naszej pracy i sesji mentoringowych, które prowadzimy. Dla nas temat zawsze był jednoznaczny, ale okazało się, że są różne spojrzenia na kwestię estymowania błędów. Dlatego postanowiliśmy przyjrzeć się przeciwnemu stanowiskowi do naszego, czyli do wyceniania błędów.  Na początek chcieliśmy zaznaczyć, że: mówimy tu o błędach, które trafiają z szeroko rozumianych środowisk produkcyjnych do zespołu, a nie o błędach wykrywanych przez sam zespół w trakcie pracy,  estymowanie w tym artykule oznacza jakąkolwiek próbę oszacowania błędu przed jego naprawieniem. Może to być oszacowanie pracy w Story pointach, w konkretnych jednostkach czasu, ale co ważne: bez próby faktycznego rozwiązania. Jednocześnie pamiętaj, że to, o czym tu piszemy to wyłącznie nasza perspektywa i do niczego nie chcemy Cię przekonywać. Dzielimy się tylko naszym punktem widzenia i chętnie poznamy Twoje spojrzenie na temat estymowania błędów. Dlaczego my nie estymujemy błędów? Zacznijmy od argumentów za tym, dlaczego naszym zdaniem nie warto wyceniać błędów. Błędy mają bardzo różny rozkład czasu realizacji – jedne z nich będą oczywiste już “na pierwszy rzut oka”, jak np. widzimy w logach, że skończyło się miejsce na dysku. Inne z kolei będą dla wykonawcy zagadką i nie da się poznać ich przyczyny bez głębokiej diagnozy i próby rozwiązania. Ta charakterystyka jest odmienna od typowych elementów Backlogu Produktu, gdzie zwykle na podstawie kryteriów akceptacji i opisu da się mniej więcej określić, co konkretnie chcemy zrobić. W przypadku błędów wiemy jedynie, że chcemy coś naprawić, ale nie mamy jasnej odpowiedzi, ile czasu nam to zajmie. Szacowanie relatywne (czyli storypointy) to jednostka w skali porównywania elementu do elementu – nie ma możliwości porównania błędu, który jest nieznany, ponieważ nie ma sposobu odniesienia dzięki któremu możemy oszacować wielkość tego błędu i czasu, jaki nam zajmie jego naprawienie (na podstawie wiedzy, którą mamy z wcześniejszych podobnych sytuacji). Wiedzę zdobywamy dopiero w trakcie pracy, rozwiązywania danego problemu. Ale wówczas proces estymacji jest już niepotrzebny. Czas rozwiązania błędu ma wyraźną różnicę pracochłonności zależną od wykonawcy oryginalnego kodu – w idealnym świecie, każdy członek zespołu deweloperskiego powinien mieć kompetencje umożliwiające naprawienie takiego błędu. Jednakże w rzeczywistości zwykle jest tak, że mamy ekspertów z wąskich obszarów (technologicznych i komponentowych). Stąd też uniwersalne wspólne oszacowanie może być trudne, jeśli konkretnej kompetencji, a czasem nawet twórcy danego kodu, zabraknie. Uwzględnianie w wycenach błędów może powodować złudne wrażenie, że zespoły dużo dostarczają – porównując to do fabryki aut: jeśli jednego dnia z linii produkcyjnej zjedzie 100 aut idealnych jakościowo i 100 kolejnych aut wymagających poprawek, a potem następnego dnia (oprócz wyprodukowania 100 nowych aut), załoga fabryki naprawi te 100 aut z poprzedniego, to czy może powiedzieć, że firma wyprodukowała przez dwa dni 300 czy 400 aut? Jeśli w zespole mierzymy Velocity, ta miara zacznie zakłamywać obraz o dostarczonej ilości elementów wartościowych, ponieważ w takiej sytuacji wliczanie poprawionych błędów tworzy złudne wrażenie, że zespoły dużo dostarczają. Velocity przestaje być wiarygodną podstawą do prognoz – miara ta nie pokazuje nam już tylko, jak dostarczamy jako zespół, traci swoje znaczenie jako podstawa do prognoz dostarczania w przyszłości. Velocity zaczyna pokazywać nam po prostu, ile pracy zespół realizuje, z tym że nie tylko nowych funkcjonalności, ale i eliminowania błędów z tych dostarczonych poprzednio. Argumenty zwolenników estymacji błędów Po przedstawieniu Ci naszych argumentów za tym, dlaczego nie estymujemy błędów, odniesiemy się teraz do argumentów zwolenników wyceniania błędów i podamy nasze kontrargumenty. Co najczęściej słyszymy od osób i zespołów, które chcą wyceniać błędy? “Dzięki oszacowaniu wiemy ile pracy mamy do zrobienia w tym błędzie” –  zespół mając przekonanie, że wie, ile jest pracy do zrobienia w danym błędzie, może nie widzieć przeszkód przed jego estymacją. Jednak tak jak już wspominaliśmy wcześniej, tr

Jak może wyglądać codzienne spotkanie w zespole, który nie używa Scruma? Może on spotykać się na codziennym stand-upie, podczas którego członkowie zespołu dzielą się tym, co jest dla nich ważne. Całość usprawnia wizualizacja pracy. Dowiesz się, jakie są praktyki codziennego stand-upu i jak wprowadzić go do zespołu. Mamy też kilka przestróg dotyczących tego spotkania. Porządny Agile · #101 – Praktyka codziennego stand-upu Sens codziennych spotkań Czy codzienne spotkania zespołów mają faktycznie sens? Jak może wyglądać praktyka takiego spotkania w zespołach, które nie korzystają ze Scruma? Spis treści Sens codziennych spotkańDlaczego warto praktykować codzienny stand-up?Praktyki codziennego stand-upuPrzykłady codziennego stand-upu w zespołach zwinnychPorady i przestrogi związane z codziennym stand-upemFAQ: Praktyka codziennego stand-upu📄Transkrypcja podcastu „Praktyka codziennego stand-upu” Temat ten pojawia się podczas prowadzonych przez nas szkoleń. Członkowie zespołów zwinnych czy ich liderzy, którzy z jakichś względów nie korzystają ze Scruma, zadają nam często pytania o korzyści płynące z codziennych spotkań, przykłady z innych zespołów czy wskazówki wprowadzenie tych spotkań w życie.  Stąd też w tym artykule odpowiemy na powyższe zagadnienia, świadomie skupiając się na spotkaniach, które nie są ściśle oparte o Daily Scrum. O Codziennym Scrumie mówiliśmy już zresztą w odcinku 25. podcastu Porządny Agile do odsłuchania, którego Cię zapraszamy. Jeśli natomiast używasz Scruma w zespole, to też warto sprawdzić cały nasz poniższy artykuł. Może on być dla Ciebie ciekawą dawką inspiracji, jak bardzo inaczej może wyglądać codzienne spotkanie. Zresztą może rozwiniecie Wasze Daily Scrumy o pewne elementy, które spodobają Ci się w podanych tutaj przykładach. Dlaczego warto praktykować codzienny stand-up? Zapewnia codzienną synchronizację, a wszyscy członkowie zespołu, bez względu na to, czy zależą od siebie, czy jakoś pośrednio sobie pomagają, mają ten sam komplet informacji i znają rozwój sytuacji. Dzięki temu mogą ze sobą dobrze współgrać. Pomaga propagować istotne informacje w zespole z możliwością natychmiastowej weryfikacji ich zrozumienia poprzez proaktywne zadawanie pytań. Daje okazję do poukładania planu pracy na najbliższy dzień, a także ustalenia istotnych różnic w zespole, czy ustalenia zmian wpływających na efekty pracy całego zespołu lub potwierdzenia, że wszystko jest w porządku i działamy dalej. Pamiętaj jednak, że takie pojedyncze spotkanie nie zastąpi Wam bieżącej komunikacji, jest to jednak tylko bardziej merytoryczna rozgrzewka na dobry początek dnia pracy. Wspiera rozwiązywanie wyzwań całym zespołem, ponieważ daje poczucie, że robimy to razem i jesteśmy połączeni jako zespół. Pozwala poczuć się częścią zespołu – dotyczy to zwłaszcza specjalistów, którzy pewne cząstki pracy wykonują samodzielnie lub w kiepsko zaimplementowanej pracy zdalnej. Takie codzienne spotkania i ta synchronizacja pozwala poczuć, że jesteśmy częścią zespołu, a nie jestem samodzielnymi elektronami. Codzienny standup jest jedną z najpopularniejszych praktyk zwinnych, którą rekomendujemy każdemu zespołowi, co poruszamy też w naszym webinarze Co to jest agile?. Praktyki codziennego stand-upu Dla osoby, która chce wprowadzić taką praktykę do swojego zespołu, mamy następujące rady: 1. Przeprowadzaj spotkanie regularnie – Ta regularność jest oczywiście zawsze kwestią umówienia się w zespole, ale najczęściej spotkania te odbywają się raz dziennie (stąd nazwa „daily”). Konkretna godzina jest do decyzji zespołu i zwykle wynika z charakteru pracy i dostępności wszystkich członków. 2. Ustal krótki, określony czas trwania – W Scrumie rekomenduje się maksymalnie 15 minut i naszym zdaniem to optymalny czas do spróbowania na start. Jeśli w zespole jest poczucie, że spotkanie tego typu powinno być dłuższe, warto ustalić sobie konkretny limit czasowy, co sprawi, że spotkanie będzie zwięzłe i każdy będzie wiedział, ile jeszcze czasu pozostało do jego końca. 3. Zapewnij, że cały zespół uczestniczy – Obecność wszystkich członków wspiera poczucie przynależności i zespołowości oraz pozwala szybko rozstrzygnąć wszelkie kwestie na styku kilku osób – spodziewane i niespodziewane.  4. Zachęcaj do dzielenia się tym, co ważne dla zespołu – Każdy zespół może mieć trochę inną specyfikę, a poszczególni specjaliści inne potrzeby, dlatego warto ustalić, jaki poziom szczegółowości rozmów nam odpowiada, które informacje są dla nas kluczowe, co chcemy poruszać na spotkaniach, od czego chcemy je rozpoczynać. Z doświadczenia wiemy, że nienajlepszą praktyką jest przeprowadzanie spotkań w formie pokazywania, jak każdy z nas jest zajęty lub ile ma zadań danego dnia. Najczęściej w zespole ważne mogą być takie kwestie, jak wynik zrealizowanych spotkań, ustalenia, które rzutują na pracę innych członków zespołu, czy planowane zmiany w produkcie czy procesie pracy. 5. Pomóż skupić się na rzecza

Co to jest agile, czym jest zwinność i jakie są jej zasady? Czy Agile równa się Scrum, czy może to dużo szersze pojęcie? Jakie korzyści płyną z wdrożenia tego podejścia w organizacji? Porządny Agile · #100 – Co to jest agile? Z tego artykułu dowiesz się następujących podstaw zwinności: Spis treści Co to jest agile? Jakie są główne korzyści agile?Jak wykorzystać agile w praktyce?FAQ: Co to jest agile?📄Transkrypcja odcinka „Co to jest agile?” Co to jest agile?  Agile to podejście do pracy zespołowej, polegająca na działania w krótkich odcinkach czasu z regularną rewizją postępów, planów oraz ich adaptacją. Podejście to wywodzi się z IT, w którym wykorzystywane jest od wielu lat, natomiast dzisiaj zdobywa coraz większą popularność także w innych branżach niemających nic wspólnego z technologiami. Jakie są główne korzyści agile? Najistotniejsze korzyści, jakie daje podejście zwinne to: Wspiera rozwiązywanie złożonych problemów biznesowych, głównie dzięki innowacyjnym pomysłom, które pochodzą od współdziałającego ze sobą zespołu,  Obniża ryzyko niepowodzenia inicjatywy, zarówno jeśli chodzi o obszar wykonawczy (czy umiemy to zrobić?), jak również biznesowy (czy robimy właściwe rzeczy?) oraz społeczny (czy ten zespół potrafi ze sobą współpracować?). Dostarcza więcej wartości z tej samej inwestycji, gdyż promuje świadomie selekcjonowanie tego, co robimy i rezygnowanie z tego, co zbędne, Biznes może szybciej zarabiać na produkcie czy usłudze, gdyż przyspiesza dostarczanie do odbiorcy tego, co wytwarza zespół przy wybranie minimalnej, aczkolwiek wartościowej wersji rozwiązania. Organizacja nie czeka na pełną, ostateczną wersję rozwiązania, a dodatkowe elementy dodawane są podczas kolejnych kroków rozwojowych,  Zwiększa zaangażowanie osób pracujących w zespole dzięki dobrze zdefiniowanemu i zrozumianemu celowi, do którego wspólnie dąży zespół oraz współpracy motywującej zespoły do działania,   Ułatwia wprowadzanie zmian w trakcie prac, co jest możliwe dzięki pracy w małych krokach. Jeśli okaże się, że trzeba skorygować kurs działania i obrać inną strategię (czy to na poziomie zespołu, czy też organizacji), to agile to umożliwia. Jak wykorzystać agile w praktyce? Podzielimy się z Tobą 4 zasadami podejścia zwinnego opatrzonymi przykładowymi praktykami, od których możesz łatwo zacząć wykorzystywać podejście zwinne. 1. Współdziałanie Jest to najbardziej rozbudowana forma współpracy, gdzie grupa osób tworzy zespół, który realizuje bardzo dobrze określony cel. Współdziałanie może występować na dwóch płaszczyznach: wewnątrz zespołu projektowego, między zespołem a klientem lub odbiorcą tego, co dostarczamy. Już samo tak bliskie współdziałanie jest pewnym rodzajem praktyki zwinnej. Przykładowa praktyka: codzienny stand’up Innym przykładem praktyki, która mocno wspiera tę silną współpracę, jest praktyka codziennego spotkania zespołu, zwanego zwykle codziennym stand’upem. Dzięki tym spotkaniom, zespoły zwinne regularnie synchronizują się w temacie obecnego postępu prac, sprawnie komunikują sobie ewentualne zagrożenia oraz dopasowują swoje najbliższe plany do zmieniającego się otoczenia. Praktyka codziennego stand’upu jest całkiem prosta w implementacji, gdyż wystarczy ustawić regularny cykl codziennego, krótkiego spotkania. Jak długo powinno trwać takie spotkanie? To zależy od zespołu, ale możesz się spotkać z wytyczną, że nie powinno trwać dłużej niż 15 minut, jednak jeśli masz duży projekt lub duży zespół, możesz potrzebować więcej czasu. Istotne jest trzymanie się założenia, że ma to być krótkie spotkanie, po którym wszyscy w zespole powinni wiedzieć, gdzie są z postępem prac i jaki jest plan na nadchodzący dzień. 2. Dostarczanie Jedną z istot tego, co to jest agile, jest dostarczanie na jak najwcześniejszym etapie małych kawałków rozwiązania, będących efektami pracy zespołu. Są ku temu dwa fundamentalne powody: po pierwsze chcemy, jak najszybciej nauczyć się, czy to, co realizujemy, odpowiada na prawdziwe potrzeby naszego klienta, po drugie chcemy jak najwcześniej zacząć dostarczać wartość biznesową. Owa wartość biznesowa może być wielorako rozumiana, w zależności od kontekstu i tego, co realizuje zespół. Mogą to być konkretne rezultaty finansowe w postaci przychodów czy oszczędności, ale również aspekty jakościowe, usprawnienia dla pracowników czy wartość dodana dla odbiorców rozwiązania. Wartość biznesową należy doprecyzować w ramach konkretnego zespołu, a następnie działając zgodnie z zasadą agile: dostarczać ją możliwie jak najwcześniej i regularnie w kolejnych krokach. Przykładowa praktyka: przyrostowość Praktyką, która wspiera dostarczanie, jest przyrostowość. Polega ona na częstym oddawaniu klientowi gotowych kawałków tego, co wytwarzamy. Te kawałki są częścią pewnej większej całości, a każdy z tych kawałków może sam z siebie dostarczać wartość biznesową i jest okazją do tego, żeby się nauczyć, czy to, co robimy i w jaki sposób to robimy, jest właściw

Na co zwracać uwagę, jeśli chcemy faktycznie uzyskać wartość ze zwinności? Jak rozpoznać sztuczną zwinność i jakie sygnały ostrzegawcze mogą wskazywać, że Agile w Twoje firmie nie działa, jak należy. Odpowiedzi na te pytania rozwiniemy w tym artykule, a punktem odniesienia jest dla nas materiał „How to detect Agile BS”, stworzony przez Radę ds. Innowacji, mieszczącą się przy Departamencie Obrony USA. Dodamy do nich własne komentarze bazujące na naszym doświadczeniu, gdyż sami widzimy, że jest wiele firm, które deklaruje pracę zgodną z Agile, jednak brakuje u nich wielu krytycznych elementów niezbędnych w podejściu zwinnym. Porządny Agile · #99 – Jak rozpoznać sztuczną zwinność? Spis treści Sztuczna zwinność – 6 sygnałów ostrzegawczychNikt z zespołu nie rozmawia i nie obserwuje użytkowników produktu w akcjiKońcowi użytkownicy produktu nie uczestniczą w procesie wytwarzania Brak ciągłej informacji zwrotnej od użytkowników do zespołu wytwórczego Zrealizowanie z góry zdefiniowanych wymagań jest ważniejsze niż dostarczenie na rynek czegoś wartościowegoInteresariusze projektu działają w izolacji od siebie Ręczne procesy są tolerowane w sytuacjach, gdy mogą i powinny być zautomatyzowane FAQ: Jak rozpoznać sztuczną zwinność?📄Transkrypcja podcastu „Jak rozpoznać sztuczną zwinność?” Sztuczna zwinność – 6 sygnałów ostrzegawczych Na wstępie dodajmy, że autorzy dokumentu często posiłkują się przykładami związanymi z wojskiem lub odnoszą się do niego. Wynika to z prostego faktu, że są oni związani z Departamentem Obrony. Nikt z zespołu nie rozmawia i nie obserwuje użytkowników produktu w akcji Odnosząc się do wojskowych przykładów, wyobraź sobie prawdziwych żołnierzy, którzy na polu walki albo w realiach ćwiczeń na poligonie korzystają z karabinu.  Zwinność jest wtedy, gdy zespół projektowy faktycznie obserwuje i ma możliwość bezpośredniego kontaktu z użytkownikiem swojego rozwiązania.  Ważne jest, aby opierać się pokusie rozmawiania z jakimś reprezentantem czy kierownikiem użytkownika, tylko z faktycznym użytkownikiem naszego rozwiązania. Możesz nawet zrobić mały eksperyment i najpierw porozmawiać z przedstawicielem użytkownika, a potem z użytkownikiem. Zobaczysz, jak diametralnie zmieni się Twoja perspektywa patrzenia na produkt i problem, jaki chcesz rozwiązać. Jest to nie do zastąpienia.  Podobnie sprawa wygląda, gdy tylko Product Owner rozmawia i obserwuje użytkownika, a cała reszta zespołu otrzymuje relacje z drugiej ręki. Każdy taki pośrednik między członkami zespołu to ryzyko zaburzenia przekazu i efektu głuchego telefonu. Końcowi użytkownicy produktu nie uczestniczą w procesie wytwarzania  Punkt ten, podobnie jak poprzedni odnosi się do użytkowników końcowych, jednak tu autorzy kładą nacisk na włączaniu użytkowników ich do procesu projektowego. Różnica między obserwacją, jak użytkownik korzysta z produktu, a zaangażowanie go w proces wytwórczy jest znacząca. Możliwość pokazania użytkownikowi produktu na wczesnym etapie jego tworzenia i otrzymanie informacji zwrotnej oraz wspólne szukanie najlepszego rozwiązania to bardzo sensowne podejście. Użytkownik będzie tu po prostu współtwórcą rozwiązania. Dobrym pomysłem może być też zaproszenie do projektu (np. w ramach warsztatu) jakiegoś przedstawiciela klienta z naszej firmy, może być to np. pracownik call center. Oczywiście, nie będzie to, to samo, co współpraca bezpośrednio z użytkownikiem końcowym, jednak zawsze to lepsze rozwiązanie, niż brak tej perspektywy odbiorcy naszego rozwiązania. Brak ciągłej informacji zwrotnej od użytkowników do zespołu wytwórczego  Trzeci punkt nadal porusza kwestię użytkownika i podkreśla, że pojedyncze interakcje z nim się nie liczą, zwłaszcza jeśli są tylko podczas startowania projektu czy inicjatywy. Chodzi o sytuację, w której zespół projektowy nie ma dostępu do informacji zwrotnej przez cały okres procesu wytwórczego. A to powinna być naturalna kolej rzeczy, że w realiach produktowych mamy kolejne wersje, kolejne iteracje, kolejne przyrosty, kolejne prototypy, które są ciągle rozwijane i doskonalone na bazie bieżącego feedbacku, który jest dostarczany w sposób ciągły. Zrealizowanie z góry zdefiniowanych wymagań jest ważniejsze niż dostarczenie na rynek czegoś wartościowego Jeśli rozłożymy to zdanie na części to pierwsze, to: „z góry zdefiniowane” – czyli przygotowany przez kogoś jakiś zakres, jakaś dokumentacja czy analiza, która powinna zostać zrealizowana w konkretnej formie, dalej mówimy o wymaganiach, które mogą uśpić czujność zespołu deweloperskiego i stać się istotniejsze niż to, co faktycznie możemy dostarczyć na rynek – wartościowy i użyteczny produkt, rozwiązujący problemy użytkowników.  Wcześniejsze punkty skupiały się mocno na użytkowniku, ten natomiast wskazuje na to, że powinniśmy być gotowi na pojawiające się zmiany w trakcie życia naszego projektu czy produktu z uwagi na napływającą informację zw

Co możesz zrobić, żeby zainteresować zarządzających Przeglądem Sprintu? Sprawdź listę naszych pomysłów na to, jak sprawić, żeby Zespół Scrumowy i zarządzający byli usatysfakcjonowani udziałem w wydarzeniu scrumowym. Mamy dla Ciebie garść wskazówek, żeby podejść do tematu porządnie. Porządny Agile · #098 – Zarządzający na Przeglądzie Sprintu Co poruszamy w tym materiale? Spis treści Kogo mamy na myśli pisząc Zarządzający na Sprint Review?Jak zorganizować Sprint Review, który zainteresuje zarządzających?Wskazówki i przestrogi dotyczące Przeglądu Sprintu z udziałem zarząduFAQ: Zarządzający na Przeglądzie Sprintu📄Transkrypcja podcastu „Zarządzający na Przeglądzie Sprintu” Kogo mamy na myśli pisząc Zarządzający na Sprint Review? Mówiąc o zarządzających mamy na myśli szeroką grupę osób, która, w zależności od struktury organizacji, może przybierać różne nazwy. Czasem jest to faktyczny zarząd firmy, w innych organizacjach są to dyrektorzy zarządzający, a innym razem to tzw. leadership team lub top management. Bez względu na nazewnictwo, chodzi nam o osoby będące na najwyższych szczeblach w danej organizacji. Osoby na tych stanowiskach zwykle mają dużo obowiązków i spotkań, dlatego, aby zechcieli pojawić się na Przeglądzie Sprintu, warto ich do tego odpowiednio zachęcić i zainteresować wydarzeniem.  Jak zorganizować Sprint Review, który zainteresuje zarządzających? Wybierz właściwy moment na zaproszenie Zadbaj o to, żeby zarządzający wiedzieli, czym jest Przegląd Sprintu Przygotuj ich, na to, co zobaczą na Przeglądzie Sprintu Dopasuj prezentację do odbiorcy Zaangażuj zarządzających w spotkanie Prezentacje prowadź od ogółu do szczegółu Pokaż rezultaty i efekty, a nie to, ile włożone zostało wysiłku Pokaż dalsze plany Poniżej rozwijamy bardziej szczegółowo powyższe punkty. 1. Wybierz właściwy moment na zaproszenie Kontekst tego, co aktualnie robi Twój zespół, ma ogromne znaczenie, jeśli chodzi o zapraszanie zarządu na Przegląd Sprintu. Nie zawsze jest sens to robić. Przykładowo, jeżeli zespół dopiero zaczyna pracę i nie ma jeszcze nic konkretnego do pokazania, to osoba z zarządu nie będzie miała się do czego odnieść. Jej obecność może być stratą czasu i okazji.  Dlatego osoby z zarządu warto zapraszać na Sprint Review, gdy faktycznie masz już coś wyprodukowane. Będziecie razem mogli o tym podyskutować oraz otrzymać wartościową informację zwrotną.  Z drugiej strony, nie ulegaj ze swoim zespołem pokusie, aby zarządzających zaprosić dopiero, gdy cały produkt jest gotowy. Lepiej otrzymać feedback we wcześniejszych fazach tworzenia produktu, a nie na sam koniec. 2. Zadbaj o to, żeby zarządzający wiedzieli, czym jest Przegląd Sprintu Osoba, która na co dzień nie ma do czynienia z podejściem zwinnym, może mieć problem ze zrozumieniem swojej roli na Sprint Review. Może tak być zwłaszcza w sytuacji, gdy agile jest dopiero wdrażany do organizacji. W takiej sytuacji osoba zarządzająca ma prawo nie wiedzieć, czego powinna się spodziewać, czego będzie się od niej oczekiwało i po co w ogóle ma się pojawić na danym spotkaniu.  Ponadto Przegląd Sprintu ma pewną specyficzną formułę, nietypową dla klasycznych spotkań zarządczych. Dlatego, aby osoby z zarządu mogły czuć się komfortowo, przekaż króciutką instrukcję z praktycznymi wskazówkami. Można w niej zawrzeć nie tylko informację o tym, czym jest Przegląd Sprintu, ale również czego od nich oczekujesz. Wskaż wprost jakie interakcje są wskazane i czego lepiej, aby nie robili. Być może unikniesz nieprzyjemnej sytuacji utrudniania przebiegu przeglądu przez nawyki zarządzających z innego typu spotkań 3. Przygotuj ich, na to, co zobaczą na Przeglądzie Sprintu Ponieważ Przeglądy Sprintu odbywają się w trakcie tworzenia produktu, to często prezentowany na nich wynik pokazuje niedokończony jeszcze produkt. Osoby z zewnątrz powinny mieć świadomość tego, że np. nie będzie zawierał wszystkich funkcji. Będą oglądać pewien etap jego rozwoju i będzie to produkt niedoskonały, z pewnością niepełny. Dodatkowo może w czasie prezentacji pojawić się niespodziewany błąd jakościowy albo może się ujawnić się błąd komunikacyjny. Aby otrzymać właściwą informację zwrotną i uniknąć błędnego wrażenia o jakości pracy zespołu, przygotuj ich na to, co zobaczą. 4. Dopasuj prezentację do odbiorcy Porada ta jest oczywiście zawsze prawdziwa, bez względu na interesariuszy zaproszonych na wydarzenie czy prezentację. Jednak w naszej opinii, osoby z wyższych szczebli organizacji, mogą potrzebować podejścia bardziej dopasowanego do ich potrzeb.  Przykładowo, zarządzający niekoniecznie muszą znać koncepcję wytwarzania oprogramowania. W związku z tym sformułowania, którymi zespoły zwinne posługują się na co dzień, mogą być dla nich obce i niezrozumiałe. To może wywołać w nich negatywne emocje. Mało kto lubi czuć się niekompetentny, kiedy oczekuje się od niego informacji zwrotnej lub komentarzy czy pytań. Dlatego warto zadbać o wyjaśnienie technicznych pojęć, których najczęściej nie

Agile w organizacji niesie za sobą korzyści, które zachęcają do wprowadzenia tego podejścia. Pierwsze transformacje miały miejsce w firmach IT, ale obecnie zwinność wychodzi poza ten obszar. Transformacja w stronę zwinności może się  wydawać z pozoru prosta. Management ma plan, którego się trzyma i realizuje transformację. W tym materiale przestrzegamy, że jest to dużo trudniejsze, niż Ci się wydaje i dowiesz się, dlaczego tak jest. Dzielimy się też poradami, które przydadzą się osobom zarządzającym transformacją. Porządny Agile · #097 – Transformacja jest trudniejsza niż myślisz Pomysł na poruszenie tego tematu podsunął nam jeden ze słuchaczy podcastu Porządny Agile. Bierze on obecnie udział w transformacji zwinnej i przyznał, że jest trudniej, niż zakładano.  Spis treści Dlaczego transformacja jest trudniejsza niż myślisz?Jak sprawniej przeprowadzić transformację?FAQ: Transformacja jest trudniejsza niż myślisz?📄Transkrypcja podcastu „Transformacja jest trudniejsza niż myślisz” Dlaczego transformacja jest trudniejsza niż myślisz? 1. Jako organizacja robisz to po raz pierwszy O transformacji zwinnej łatwo się słucha, jednak trudniej już ją przeprowadzić. Często słyszy się głównie o sukcesach na tym polu i łatwo dojść do wniosku, że nie ma w tym nic skomplikowanego. Prawda jest taka, że jest to bardzo złożona zmiana. Organizacja, która robi to po raz pierwszy, zapewne natknie się na przeszkody, o których nikt by nawet nie pomyślał.  Tak rozległych zmian mogło po prostu nie być w organizacji od lat. Zresztą jest to też częsty argument, aby w ogóle zainicjować transformację – nastąpił zastój i trzeba przełamać status quo. Trudno tu niestety odwołać się do doświadczenia firmy czy pracowników. Stąd można nie docenić ciężaru tego typu zmiany. 2. Duża część osób w firmie robi to po raz pierwszy To kolejny powód, mocno zresztą powiązany z pierwszym. W organizacji po prostu brak kompetencji osobistych i doświadczenia. Może to powodować zbytni optymizm w ocenie skali zmiany i jej rozległości na linii czasu. Zmiana dotyczy przecież też ludzi, a ponadto zwykle jest realizowana siłami wewnętrznymi. To zarządzający organizacją chcą tę zmianę przeprowadzić, a zazwyczaj nigdy czegoś takiego nie robili. Jedynie czytali o zmianie, słuchali podcastów lub widzieli case studies, które są często mocno okrojone i skupiają się na sukcesach. Nawet 2-dniowe szkolenie może nie wystarczyć, albo wręcz wytworzyć przekonanie, że wszystko jest w miarę oczywiste i łatwe. 3. Transformacja dotyczy też Ciebie Zmiana dotyczy organizacji, zmiana dotyczy ludzi w niej pracujących, ale zmiana też dotyczy Twojej osoby. O wiele prościej jest nam dostrzegać elementy do zmiany w konkretnych obszarach organizacji lub u innych ludzi niż u nas samych. Natomiast niezbędna jest refleksja nad tym, co powinno ulec zmianie w obrębie Twojego stanowiska, podejścia do pracy czy nawyków. Zwykle o tym się zapomina, kiedy planuje się przeprowadzenie transformacji. Może tak być, że coś osobiście utracisz (np. zakres stanowiska, kontrolę, ingerencję w procesy firmy) w wyniku zmiany. Wówczas potrzeba dużej odwagi, aby i te obszary uwzględnić w procesie. 4. Spotkasz się z oporem, większym niż myślisz Ludzie różnie reagują na zmianę i opór pojawia się zawsze. Może być jednak tak, że spotkasz się z o wiele szerszym oporem, niż zakładasz. Mogą się pojawić najróżniejsze powody tej niechęci do zmiany, często różniące się od siebie i dotykające różnych obszarów. Opór może też wyniknąć z błędów, jakie popełnisz podczas komunikacji zmiany. Zostaniesz źle zrozumiany/a i sprawi to, że więcej osób będzie miało postawę negatywną. Pamiętaj jednak, że sama komunikacja nie rozwiązuje tego problemu. Organizację tworzą ludzie, którzy różnią się między sobą doświadczeniami, stażem, podejściem do pracy i firmy, a także swoim nastawieniem. Pewnie znajdują się w niej osoby, które podchodzą do wszystkiego bardzo entuzjastycznie. Będą jednak też takie, które zawsze wszystko negują i widzą same złe strony obrotu spraw. Przygotuj się na to. 5. Na początku transformacji będzie gorzej, żeby potem mogło być lepiej Zawsze na początku zmian zdarzają się niepowodzenia, a my członkowie zespołów potrzebują czasu na naukę nowego sposobu pracy. Do tego oczywiście potrzebne są chęci, a następnie konkretne działania. Pewnych nawyków muszą się też oduczyć, a inne zastąpić. Przykładowo, jeśli Twój styl pracy był dotychczas dyrektywny i zaczynasz delegować więcej do zespołu, będzie on potrzebował czasu na naukę. Ty z kolei będziesz musiał/a zaufać, że podejmują dobre decyzje i zrobią wszystko dobrze. W czasie szkoleń, gdy robimy ćwiczenie związane z samoorganizowaniem się zespołów, podczas jego realizacji często pojawia się dużo chaosu. Nie wiadomo do końca kto, gdzie i kiedy ma coś wykonać, pojawiają się sprzeczne pomysły, ludzie na siebie krzyczą i biegają w przeciwnych kierunkach. W takiej mikroskali ten efekt chaosu pokazuje, jak wyglądają początki samoorganizacji.

Jakie korzyści może przynieść praca w krótszych Sprintach? Często w naszej pracy spotykamy zespoły, które pracują w Sprintach trwających nawet 3-4 tygodnie. Naszym zdaniem krótsze Sprinty zwykle są korzystniejsze i pokażemy Ci konkretne argumenty, które to uzasadniają. Dowiesz się też, jak możesz skrócić Sprinty w Twoim zespole. Porządny Agile · #096 – Korzyści z krótszych Sprintów Ile powinny trwać Sprinty? Jakie są korzyści z krótszych Sprintów? Co zrobić, aby skrócić Sprinty w zespole? Na powyższe pytania odpowiemy w tym artykule. Osobiście uważamy, że krótkie iteracje mają większy sens i poprzemy to konkretnymi argumentami. Jednocześnie podzielimy się swoim doświadczeniem, prezentując porady, jak możesz skrócić Sprinty w swoim zespole.  Spis treści Jakie są korzyści z krótszych Sprintów?Jak skrócić iteracje w zespole?FAQ: Korzyści z krótszych Sprintów📄Transkrypcja podcastu „Korzyści z krótszych Sprintów” Poprzez długie Sprinty mamy na myśli takie, które trwają 3, a nawet 4 tygodnie i mimo że nie są one mocno popularne, to jednak uważamy, że warto poruszyć ten temat, gdyż jednak wciąż je spotykamy. Jakie są korzyści z krótszych Sprintów? Poniższe korzyści poukładaliśmy w kolejności, która odzwierciedla proces pracy zespołu zwinnego. Krótszy Sprint: promuje dekomponowanie pracy – wynika to z tego, że abyśmy zmieścili się z planowaną do wykonania w ramach Sprintu pracą, musimy włożyć w to większy wysiłek, a to z kolei często prowadzi nas do dekompozycji. Dzięki temu jesteśmy w stanie lepiej zrozumieć, co jest do zrobienia, a także możemy szybciej dostarczyć wartość.Jeżeli temat dekompozycji Backlogu Produktu jest dla Ciebie interesujący, zapraszamy nasz webinar, który znajdziesz pod adresem porzadnyagile.pl/dekompozycja. wspiera selekcję wartości i odrzucanie elementów zbędnych – łączy się to ze wspomnianą wcześniej dekompozycją, która wskaże nam, które elementy produktowe są faktycznie wartościowe dla klientów, a które niekoniecznie. Może się na przykład okazać, że ustawienia języka, które były ukryte pod ogólnym hasłem „ustawienia”, nie są aż tak istotne i prawdopodobnie będą używane bardzo rzadko. Taka dekompozycja i krótsze Sprinty motywują do wybierania rzeczy, które naprawdę należy zrobić, bo idą za nimi konkretne uzasadnienia. To czy te pozostałe rzeczy, które zostały uznane za mniej wartościowe, będziemy implementować w kolejnej iteracji czy nie, jest już decyzją biznesową. ułatwia planowanie – mamy tu krótszy horyzont czasu do zaplanowania, dzięki czemu ustalenie Celu Sprintu będzie prostsze i bezpieczniejsze. Z naszych doświadczeń wiemy, że im dłuższy czas, tym większa szansa, że nasz pierwotny plan się rozjedzie z uwagi na różne nieprzewidziane sytuacje, których wystąpienie jest mniejsze w krótszym odcinku czasu.  daje częstszą okazję do zmiany – jest to potrzebne z perspektywy biznesowej, zwłaszcza jeśli rynek często się zmienia, pojawiają się nowe okazje lub jakieś ryzyka. W takiej sytuacji dłuższe Sprinty są przyczyną tzw. wrzutek lub przerwania Sprintu i zmiany jego celu. Krótsze Sprinty pozwalają na większą elastyczność i dają szybsze okazje do zmiany kierunku i celu kolejnego Sprintu. zachęca zespół do wspólnej pracy – zwykle zaplanowanie pracy na trochę krótszy okres, może wymagać omówienia pewnych rzeczy razem z zespołem. W przypadku dłuższych Sprintów często widzimy, że członkowie zespołów po prostu biorą jakieś zadania i mają podejście: na koniec Sprintu jakoś to będzie, bo przecież Sprint jest długi. Jak mamy tylko tydzień, to musimy się dosyć dobrze zastanowić, kto na kogo czeka i jak będziemy współpracować oraz jak doprowadzimy do tego, że w tym dosyć krótkim czy relatywnie krótkim okresie, na koniec Sprintu pojawi się coś użytecznego, namacalnego, co będziemy mogli sklasyfikować jako sensowny przyrost do rozwijanego produktu. zmniejsza złożoność techniczną rozwiązania – w krótkim Sprincie nie jesteśmy w stanie przekombinować ze złożonością rozwiązania i siłą rzeczy otrzymujemy prostsze rozwiązania od strony technicznej. Prostszy produkt, który zostanie wytworzony w takim krótszym Sprincie, będzie też prostszy do dalszego procesowania. Łatwo go będzie wdrożyć, łatwo będzie można sprawdzić jego jakość.Oczywiście zakładamy tu, że zespół nie wdraża co parę minut czy godzin, tylko robi to np. raz na Sprint. umożliwia częstsze uzyskanie informacji zwrotnej –  dotyczy to sytuacji, gdzie na koniec Sprintu lub iteracji odbywa się jakaś forma przeglądu, spotkania z klientem lub interesariuszami i prezentujemy efekt pracy. Częściej otrzymujemy komentarze, co wyszło sensownie, a co można usprawnić i co dodamy do Backlog Produktu. Mamy tu na myśli rzecz jasna dodatkowe spotkania, nie tylko Przegląd Sprintu. ujawnia niedoskonałości procesu – pomagają odkryć wąskie gardła procesu, technologii czy na poziomie międzyludzkim, które mogą zostać niezauważone przy dłuższych Sprintach, a spowalniają pracę. daje częstszą ok

Czym jest reestymowanie? Poznaj taktyki i podejścia, które są przydatne przy reestymowaniu. Nie zabraknie też przestróg związanych z ponownym oszacowaniem. Porządny Agile · #095 – Czy reestymować pracę? Jak podejść do reestymacji, czyli ponownego szacowania wyceny? Jakie są taktyki wykorzystywane w reestymacji oraz na co uważać? Spis treści Czym jest reestymacja?Podejścia stosowane do reestymacjiReestymowanie pracy – porady natury ogólnejFAQ: Czy reestymować pracę?📄Transkrypcja podcastu „Czy reestymować pracę?” O estymowaniu opowiadaliśmy w 19. odcinku naszego podcastu Porządny Agile, dlatego nie będziemy tutaj ponawiać tego wątku, tylko zachęcamy Cię do przesłuchania tego odcinka. Skupimy się stricte na reestymowaniu, temacie, który wyszedł podczas niedawnych warsztatów u jednego z klientów. Czym jest reestymacja? Reestymacja to po prostu aktualizacja estymaty, czyli aktualizacja oszacowania. Czasem jest to estymata mniejsza, kiedy odkrywamy, że tej pracy jest mniej, a może to być estymata większa, gdy odkrywamy, że pracy jest więcej.  Szczególnym, ale i jednocześnie najczęstszym, przypadkiem reestymaty jest sytuacja, gdy mamy zadania nieskończone w jednym Sprincie, jednak prace nad nimi są już mocno zaawansowane. Wówczas pojawia się dylemat czy ponownie to reestymować. Do tego wątku powrócimy w dalszej części artykułu. Innym powodem reestymacji może być sytuacja, w której wycena pierwotna po jakiejś późniejszej analizie lub rozpoczęciu pracy przez zespół okazuje się zła. Może też pojawić się jakaś nowa okoliczność czy wiedza, która powoduje, że dotychczasowa estymata przestaje być adekwatna do bieżącego stanu wiedzy. Co ważne, mówimy tu o przypadkach, gdy konkretna praca została już wybrana do Backlogu Sprintu, do Sprintu lub konkretnej iteracji. Aktualizację estymat z Backlogu Productu realizuje się na wszelkiego rodzaju Refinementach. Podejścia stosowane do reestymacji Możemy wyróżnić kilka scenariuszy podejścia do reestymacji jakie możemy zastosować. Omówimy teraz 4 z nich. 1. Nigdy nie reestymujemy Ta zasada mówi, że co by się nie działo, to nie zmieniamy pierwotnej estymaty. Nie ma dla nas znaczenia, czy praca została już rozpoczęta, ale nie jest skończona, czy są jakieś nowe informacje, czy po prostu wystąpiły nowe okoliczności. To twarda, a jednocześnie prosta i klarowna zasada, która bardzo upraszcza temat. Nie musimy otwierać nowych dyskusji, nie mamy nowych dylematów. Konsekwencją tego może być to, że Velocity będzie skakać. Zwłaszcza w zespołach, które nie kończą zadań w jednym Sprincie. Jeśli między Sprintami przyjdzie trochę więcej zadań, to w jednym z tych Sprintów bardzo wyraźnie spadnie velocity. Natomiast w kolejnym Sprincie, otrzymamy bardzo dużo Story Pointów z poprzedniego Sprintu. Tu z kolei skok Velocity może być bardzo wysoki. Innym minusem tego podejścia jest to, że może ono utrudniać planowanie. W zespołach, które oceniają ilość pracy do wykonania w Sprincie poprzez dobór pewnej ilości Story Pointów, zespół może przestać wierzyć w te wyceny.  2. Reestymujemy pracę do dokończenia Tu nasza nowa estymata będzie określać tylko tę pracę, która pozostała nam do wykonania w kolejnym Sprincie, czy w kolejnej iteracji. Zaletą takiego podejścia jest to, że mamy prawdziwą informację ile pracy zostało do wykonania, a to pomaga zespołowi w planowaniu (jeśli bazują na swoim Velocity i Capacity). Jednocześnie skoki Velocity nie powinny mieć miejsca, a prędkość pracy zespołu się urealni.  Minusem z kolei jest to, że zespół tak jakby “gubi” Story Pointy za poprzedni Sprint i to przepada. Ryzykiem z kolei może być to, że gdy podchodzimy ponownie do reestymacji tematu, który już dotknęliśmy, to bardzo uznaniowo oceniamy procent postępu prac i na tej bazie proporcjonalnie zmieniamy estymatę. To sprawia, że nasza estymata nie będzie precyzyjna, o ile w ogóle możemy mówić o precyzji w tym obszarze. 3. Reestymujemy wielkość elementu produktu Podobne podejście do poprzedniego, gdzie reestymujemy wielkość elementu produktu. We wcześniejszej taktyce np. zespół pierwotnie ocenił coś na trzynastkę, po czym wykonał dużą część pracy, więc estymuje do piątki i wchodzi do następnego Sprintu z oceną wielkości pięć Story Pointów. Tu natomiast zespół bierze do pierwszego sprintu trzynastkę. Pracuję nad nią i przed rozpoczęciem następnego Sprintu lub nawet w trakcie Sprintu, jeśli zajdzie potrzeba reestymaty (np. okazuje się, że zadanie jest o wiele większe i zespół oceniłby je na dwudziestkę), to dokonuje się oceny zadania na nowo, wpisując nową wartość w tej pozycji, czy w tym polu estymata. I od tego momentu to zadanie staje się dwudziestką.  Takie podejście powoduje, że ta wycena jest urealniona i wspiera prognozowanie oraz może służyć do wyciągania dalszych wniosków.  Niestety może tu być trochę takie czarowanie statystyk, przez co nie do końca rekomendujemy to podejście. Zdarza się nam spotkać zespoły, które wykorzystują to do poprawienia Velocity, aby lepiej w

Czym są kryteria akceptacji? Czym się różnią od Definicji Ukończenia? Przedstawiamy co to są kryteria akceptacji w oparciu o przykłady z życia. Podzielimy się też z Tobą praktycznymi wskazówkami, jak z nich prawidłowo korzystać. Porządny Agile · #094 – Kryteria akceptacji W tym artykule znajdziesz następujące treści: Spis treści Czym są kryteria akceptacji?Jak w praktyce dobrze korzystać z kryteriów akceptacji?FAQ: Kryteria akceptacji📄Transkrypcja podcastu „Kryteria akceptacji” Ponieważ kryteria akceptacji to praktyka zwinna stosowana powszechnie, stąd nie musisz używać konkretnie Scruma, by z niej skorzystać. Warto pamiętać, że Przewodnik po Scrumie nie wymaga stosowania kryteriów akceptacji jako elementu obowiązkowego. Czym są kryteria akceptacji? Kryteria akceptacji to z góry ustalone warunki, które produkt, projekt albo ich fragmenty muszą spełnić, aby zostały zaakceptowane. Mówiąc prościej, są to kryteria, po których poznamy, że zrealizowaliśmy to, co chcieliśmy. W praktyce najczęściej mają postać kilku zapisanych punktów, które ustala zespół i jego otoczenie odnośnie do tego, co ma zostać zrobione.  Kryteria akceptacji dobrze pokazać na przykładach. Załóżmy, że twój zespół dochodzi do momentu, w którym szykuje się do wytworzenia opcji logowania do aplikacji. W tym przypadku można ustalić następujące kryteria akceptacji: Hasło musi się składać z minimum 8 znaków. Można się zalogować przy użyciu konta z innego serwisu. Widoczna jest formułka prawna o treści przygotowanej przez dział prawny (w realnej sytuacji tutaj powinna być konkretna treść tej formułki). Wpisanie błędnego loginu i hasła podświetla pole do wpisywania i wyświetla poniżej komunikat o błędzie: błędny login lub hasło. Można zaznaczyć checkbox: Zapamiętaj mnie na tym urządzeniu, który podtrzyma sesję użytkownika i nie będzie wymagał kolejnych logowań.  Oczywiście kryteriów akceptacji w tym przykładzie mogłoby być więcej, natomiast podaliśmy tylko kilka przykładowych. Patrząc na powyższe kryteria widać, że jedne kryteria mówią o zachowaniu systemu, inne określają konkretne wymagania, jakie mają być spełnione. Jeszcze inne będą mówić o tym, jaki konkretny efekt ma uzyskać użytkownik. Jak w praktyce dobrze korzystać z kryteriów akceptacji? Poniżej znajdziesz 7 porad, które przygotowaliśmy na bazie naszego doświadczenia faktycznej pracy z zespołami zwinnymi. 1. Nie musisz mieć idealnych kryteriów akceptacji przed rozmową z zespołem To często poruszana kwestia podczas naszych rozmów z Product Ownerami, którzy nie wiedzą, w jakim stopniu powinni być przygotowani do rozmowy z zespołem. Nie musisz znać wszystkich detali i szczegółów, żeby rozpocząć rozmowę. To właśnie wspólna dyskusja jest okazją do tego, by wyłonić istotne elementy. Przed rozmową z zespołem przygotuj wstępne założenia, np. że można zalogować się do serwisu bez rejestracji. Dopiero w toku pracy warsztatowej ustalicie wraz z zespołem na przykładach, co konkretnie to oznacza i jakie macie możliwości techniczne. Podobne dylematy mogą mieć też analitycy lub osoby wytypowane do przygotowania elementów Backlogu Produktu. Przestrzegamy przed przesadną ambicją w przygotowywaniu się do rozmowy. Nieświadomie można doprowadzić do sytuacji, w której kryteria akceptacji stają się zamkniętą, ostateczną formą specyfikacji dla zespołu. W wyniku nadgorliwości może bowiem zniknąć efekt współpracy, wspólnego odkrywania, rozumienia i dodawania stopniowo kolejnych detali konkretnej pracy do wykonania.  2. Pisz kryteria akceptacji grupowo Wspólna praca nad kryteriami akceptacji daje okazję do wykorzystania mądrości zespołu. Wróćmy do przykładu z logowaniem. Product Owner lub interesariusz biznesowy wymyśla logowanie, nie wiedząc, że warto zadbać o dwuskładnikowe uwierzytelnianie. Dzięki pracy grupowej osoba, która zna się na bezpieczeństwie, może wskazać minusy takiego rozwiązania. Może też zaproponować dodatkowe kryteria, które zwiększą bezpieczeństwo. Rzecz jasna istnieją kryteria, które są oczywiste i nie trzeba nad nimi zespołowo dywagować. Każdy sam buduje sobie wyczucie, kiedy warto zaangażować zespół, aby zobaczyć inną perspektywę czy odkryć inny sposób rozwiązania konkretnego problemu. 3. Twórz kryteria, które są przydatne całemu zespołowi Zwykle zespoły pracujące zwinnie są zespołami cross-funkcjonalnymi. Oznacza to, że posiadają wszystkie potrzebne kompetencje (np. programista, tester, analityk, specjalista od obsługi klienta), aby ograniczyć zależności zewnętrzne i od samego początku prac wytwórczych holistycznie patrzeć na produkt. Całościowe spojrzenie na produkt ma swoje odzwierciedlenie w procesie tworzenia kryteriów akceptacji. Niestety często widzimy zespoły, które całkiem nieźle podchodzą do kryteriów akceptacji, ale widzą je wyłącznie z jednej perspektywy, np. programisty. Może to prowadzić do sytuacji gdy pomimo, iż kryteria akceptacji są rozległe, to nie dają testerom podstawy stworzenia scenariuszy testowych. Zdecydowanie rekomendujemy podejście,

Praca z organizacją to wszystkie zmiany, które są do zrobienia poza zespołem, ale nie wydarzą się samoistnie. Praca Scrum Mastera z organizacją to dopełnienie usprawnień i zmian, które są do zrobienia. Mogą to być zmiany procesów, wprowadzanie nowych narzędzi czy kolejne kroki transformacji zwinnej. Przedstawiamy przykładowe obszary, w których możesz działać jako Scrum Master w pracy z organizacją. Potraktuj je jako inspirację. Zwracamy też uwagę, na co powinno się szczególnie uważać. Porządny Agile · #093 – Praca Scrum Mastera z organizacją Na czym polega praca Scrum Mastera z organizacją? Jak ją zdefiniować i jakie ryzyka mogą się pojawić, pracując z organizacją jako Scrum Master? Postanowiliśmy poruszyć to zagadnienie, gdyż był to jeden z wątków poruszanych w pracy mentoringowej Kuby ze Scrum Masterką w firmie klienta. W czasie owej rozmowy wyszło, że temat ten może być dla części społeczności zwinnej nie do końca jasny.  Spis treści Na czym polega praca Scrum Mastera z organizacją? Jak ją zdefiniować i jakie ryzyka mogą się pojawić, pracując z organizacją jako Scrum Master?Przykłady pracy Scrum Mastera z organizacjąPraca Scrum Mastera z organizacją – na co uważać? FAQ: Praca Scrum Mastera z organizacją📄Transkrypcja podcastu „Praca Scrum Mastera z organizacją” Dlatego też w tym artykule zdefiniujemy temat pracy Scrum Mastera z organizacją, posiłkując się przykładami z życia, a także podać ewentualne zagrożenia z niej wynikające.  Czym jest praca Scrum Mastera z organizacją? Zacznijmy od trochę już starej, choć wciąż widocznej w Scrum Guide definicji, która mówi, że Scrum Master ma odpowiedzialność za pracę w trzech obszarach: obszar pracy z Deweloperami czy z Zespołem Scrumowym nad kwestią wytwarzania, a innymi słowy, nad codziennością zespołu, obszar pracy z Product Ownerem wokół Product Backlogu, Refinementu, a także kontaktów z Interesariuszami, obszar pracy z organizacją, będąca dopełnieniem usprawnień i zmian w firmie, aby Scrum dobrze funkcjonował. Może to obejmować pracę nad procesami, narzędziami czy też kolejne kroki w transformacji zwinnej. Mówiąc jeszcze prościej, praca Scrum Mastera z organizacją, to jest cała praca, która jest do wykonania przez Scrum Mastera poza zespołem. Przykłady pracy Scrum Mastera z organizacją Podzielimy się teraz z Tobą 10 przykładami, które obrazują, na czym ta praca Scrum Mastera z organizacją może polegać. Pamiętaj jednak, że w każdej organizacji obszary te mogą wyglądać zupełnie inaczej i nie traktuj naszych przykładów jako wyroczni czy zamkniętej listy. Podajemy je bardziej jako inspirację i pomoc w lepszym zrozumieniu tego zagadnienia.  1. Poukładanie odpowiedzialności produktowej zespołów scrumowych Zadanie to wynika z tego, że bardzo często firmy, które dopiero zaczynają pracę ze Scrumem, mają w jakiś sposób skonstruowane zespoły. Brak tam jednak pewnego porządku, w którym wiadomo, za co odpowiada konkretny zespół. Trudno to ustalić tylko na poziomie pojedynczego zespołu, gdyż ten proces budowania odpowiedzialności produktowej dotyczy wszystkich. Być może jakieś zespoły przekażą pewne produkty do innych zespołów, a dostaną jakieś nowe produkty. Być może jakiś duży produkt zostanie podzielony na mniejsze części itd. To wszystko trzeba rozłożyć na jakiejś mapie, na której jasno będzie widać, z jakim tematem, do jakiego zespołu interesariusz czy inny zespół powinien się kierować. Ważne jest też aktualizowanie tego podziału i szukanie usprawnień, aby pracy była jeszcze bardziej efektywna. 2. Poprawa procesu wdrożeniowego i doprowadzenie do częstszych wdrożeń Jedną z cząstek zwinności jest właśnie to, że możemy częściej wdrażać i dostarczać wartość biznesową. Pozwala to też na regularne eksperymenty z użytkownikiem.Zazwyczaj jest to duże przedsięwzięcie, żeby tę kwestię poprawić w organizacji. Jednak, zamiast robić rewolucję, zachęcamy podejść do tego stopniowo i jeśli np. obecnie wdrożenia są raz na rok, to doprowadźmy do tego, aby były raz na pół roku, potem raz na kwartał, miesiąc itd. Nawet jeśli wdrożenia są codziennie, to zawsze jest opcja na poprawę tego procesu, jego przyspieszenie, zabezpieczenie czy wprowadzenie wdrożeń na żądanie. Zwłaszcza w organizacjach, w których proces wdrażania jest rzadki lub uciążliwy, to pozytywne rezultaty, np. na takich miarach transformacyjnych, jak Time To Market, da się relatywnie prosto uzyskać poprzez możliwości częstego wdrażania. Oczywiście nie oczekujemy od Scrum Mastera, że ustawi jakieś mechanizmy związane z Continuous Integration czy Continuous Deployment. Jego rolą jest uświadomienie sobie i organizacji, dlaczego to jest ważne i jakie korzyści przyniesie. 3. Podniesienie jakości wytwarzanego produktu jako całości Wiadome jest, że każdy zespół pracujący w Scrumie, odpowiada za jakość wydawanych przyrostów. Natomiast dobrym punktem styku na poziomie całych zespołów i takiego wyjścia do organizacji może być na przykład ustalenie pewnej konkretnej strategii spłacania długu

Jeśli jesteś szefem zespołu lub szefem danej grupy specjalistów, to możesz skorzystać z naszych rad na temat Twojej roli w Scrumie. Jedna z naszych podpowiedzi, to organizowanie wymiany wiedzy. Porządny Agile · #092 – Rola lidera merytorycznego w Scrumie Na czym polega rola szefa konkretnego zespołu w Scrumie i co należy do jego obowiązków? Poznaj wskazówki, jakie mamy dla liderów merytorycznych w Zespołach Scrumowych.  Spis treści Rola lidera merytorycznego w Scrumie – nasze porady i wskazówkiZbuduj wizję swojego obszaruDbaj o miary swojej sferyKształtuj warunki i narzędzia pracyWspółpracuj z innymi liderami obszarówDziałaj z zespołem w porozumieniu z nimOpiekuj się ścieżką rozwojuOrganizuj wymiany wiedzyRozwijaj ludzi ze swojego zespołuFAQ: Rola lidera merytorycznego w Scrumie📄Transkrypcja podcastu „Rola lidera merytorycznego w Scrumie” Ostatnio poruszaliśmy temat roli managera w Scrumie, tu z kolei zgłębimy ten temat i skupimy się na konkretnym typie managerów – liderów merytorycznych. Są to managerowie konkretnej grupy specjalistów (np. testerów). Jak sama nazwa wskazuje, odpowiadają oni również merytorycznie za swój zespół i rozwój zawodowy jego członków. Rola lidera merytorycznego w Scrumie – nasze porady i wskazówki Zbuduj wizję swojego obszaru Chodzi tu o wysokopoziomowe wyobrażenie tego, jak obszar który masz pod swoimi skrzydłami, będzie się rozwijał i do czego będziecie wspólnie dążyć. Ważne, by wykształcić perspektywę jak jako lider chcę, żeby mój obszar funkcjonował i jak będę realizował ten proces zmiany. Pracując w centrum Agile w jednej z firm, sami doświadczyliśmy, jak bardzo jest to wartościowe ćwiczenie, ponieważ przypominało rozproszonemu na co dzień zespołowi, dokąd tak naprawdę idziemy, co jest dla nas ważne, kto jest naszym klientem, co mamy dostarczyć organizacji i co tak naprawdę chcemy osiągnąć. Dbaj o miary swojej sfery Mamy tu na myśli posiadanie konkretnych miar (jakościowych czy np. technologicznych), które wskazują, jak funkcjonuje obszar, za który odpowiadasz. Przykładowo, jeżeli jesteś liderem zespołu testerów i odpowiadasz za ich kompetencje merytoryczne, to warto ustalić jakie miary pokażą Ci poziom tego, co na co dzień robicie. Miary te umożliwią też obserwację realizowanych zmian i ich ewentualne usprawnianie, jeśli nie przynoszą oczekiwanych rezultatów. Pokażą też długofalowe trendy. Nie chodzi tu o miary, jakie ma Zespół Scrumowy i analizuje je na Retrospektywie. To mają być miary typu wydajność czy stabilność. Pamiętaj też, aby budować zrozumienie w zespole, po co te miary funkcjonują, aby nie były świadomie lub nieświadomie zafałszowane, np. poprzez nierzetelne czyszczenie ticketów. Kształtuj warunki i narzędzia pracy Buduj systemowe wsparcie, np. nowoczesne narzędzia, odpowiednie środowiska i techniki pracy, które będą de facto realizować tę wizję, o której pisaliśmy w pierwszym punkcie. Propaguj te metody i narzędzia, nawet jeśli nie są powszechne w Twojej organizacji i o ile to możliwe przesuwaj granicę ich wykorzystywania. Innymi słowy, wyposaż członków swojego zespołu w konkretne rozwiązania, które pozwolą im lepiej pracować. Ten punkt będzie szczególnie istotny, jeśli dopiero co dołączyłeś do organizacji i zaczynasz dostrzegać, że narzędzia tutaj wykorzystywane są nieefektywne lub niekompatybilne z podejściem, który chcesz promować. Przykładem może być tu często przez nas obserwowana zmiana systemu obsługi repozytorium kodu, czyli na przykład przejście z SVN-a na GIT-a. Może być tak, że osobiście będziesz musiał wykonać kawałek pracy, bo np. nikt wcześniej tego nie robił, nikt w firmie nie ma odpowiednich kompetencji. Może być też tak, że będziesz musiał porozmawiać z różnymi osobami, np. Product Ownerami, aby wygospodarlowali czas na daną rzecz w Backlogu Produktu. Współpracuj z innymi liderami obszarów Taka współpraca może mieć szczególne znaczenie, kiedy chcesz dobrze doprecyzować wszelkiego rodzaju punkty styku konkretnych kompetencji, np. testerów z programistami, którzy stanowią oddzielne zespoły. Jeśli zechcesz w procesie usprawniania pracy dołączyć do zespołu testera w ramach pilotażu i przetestowania działania w inny sposób, to warto spotkać się i przedyskutować wszelkie niuanse dotyczące tej zmiany. W dłuższej perspektywie przyjdzie też potrzeba refleksji nad tym, jak ten konkretny tester odnajduje się w zespole, jak się zmienia rola dewelopera, czy widać pozytywne rezultaty. Tu właśnie bardzo pomocne będzie włączenie liderów innych obszarów, np. lider merytoryczny osób odpowiadających za front-end lub za back-end. Z drugiej strony, chodzi też o to, żeby uniknąć budowania silosu czy lokalnej optymalizacji. Jest to duża pokusa, która i u nas się pojawiała. Jeśli będziemy zoptymalizowani tylko na siebie, będziemy idealni, będziemy perfekcyjni i będziemy bardzo dużo wymagać od innych profesji, to może to powodować konflikty, np. pomiędzy analitykami a resztą zespołu. Tu właśnie współpraca z liderami innych obszar