Porządny Agile

Scrum Guide nie określa wprost roli managera w Scrumie, dlatego często taka osoba ma wątpliwości, jaka jest właściwie jej rola w podejściu zwinnym. Z tego odcinka dowiesz się czym może zajmować się manager w Scrumie, a czego lepiej nie robić. Pomoże Ci to zrozumieć Twoją rolę w Scrumie i rozplanować pracę. Porządny Agile · #091 – Rola managera w Scrumie Czym może zajmować się manager w Scrumie? Jaka jest jego rola w podejściu zwinnym? W jakich aktywnościach Scrumowych manager powinien uczestniczyć,  a czego lepiej, aby nie robił?  Spis treści Jaka jest rola managera w Scrumie? Jakich zachowań unikać jako manager w Scrumie?FAQ: Rola managera w Scrumie📄Transkrypcja podcastu „Rola managera w Scrumie” Poruszamy ten temat, ponieważ sam Scrum Guide nie określa wprost roli managera i często spotykamy się z managerami, którzy mają różnego rodzaju rozterki w tej właśnie kwestii. Postaramy się rozwiać potencjalne wątpliwości i pomożemy efektywnie planować pracę. Zacznijmy od wyjaśnienia kogo mamy na myśli, mówiąc o managerze, gdyż definicja tej roli jest bardzo kontekstowa i zależy w dużej mierze od tego, jak dana organizacja funkcjonuje i sama sobie to definiuje. W naszym przypadku będziemy mówić o osobie, która zajmuje się zarządzaniem ludźmi, w szczególności budowaniem zespołu, kwestią wynagrodzeń, podwyżek i awansów, a także przekazywaniem celów i dbaniem o ich realizację. Taka osoba zwykle ma również jakiś budżet zarządczy, pomaga w rozwiązywaniu problemów w zespole i utrzymaniu pewnych standardów pracy. Nie będziemy tu mówić o członkach zarządu większych firm, dyrektorach i osobach ze średniego managementu, a także nie o managerach będących jednocześnie deweloperami w Zespołach Scrumowych.  Jaka jest rola managera w Scrumie?  Będąc managerem powinieneś przede wszystkim: 1. Być do dyspozycji na Refinemencie – często możesz mieć dodatkowy kontekst, którego zespół nie ma lub nie zawsze go zauważy. Twoja perspektywa i doświadczenie organizacyjne może być bardzo przydatne zespołowi. Zadawaj pytania pogłębiające, dopytuj o lepsze rozwiązania, prowokuj do myślenia długofalowego, które nie zawsze jest brane pod uwagę. Zapytaj np. o utrzymywalność produktu, jego rozwój czy realizację długoterminowej wizji technologicznej czy organizacyjnej.Nie musisz być bardzo aktywny na Refinemencie, chodzi o to, abyś był obecny i reagował w miarę potrzeb – gdy zespół czegoś nie zauważa, coś pomija, o czymś nie wie. Nie chodzi też o to, abyś dyktował konkretne rozwiązania, po prostu wchodź w rozmowę, zadawaj dobre pytania i zwracaj uwagę na istotne kwestie i dodatkowe możliwości. Oczywiście owa obecność i związana z nią aktywność na Refinemencie w dużej mierze zależy od dojrzałości i doświadczenia zespołu Scrumowego. Młody zespół lub z nowym Product Ownerem czy Scrum Masterem może potrzebować większego wsparcia ze strony managera. I odwrotnie, zgrany i osadzony w kontekście biznesowym zespół, który dobrze zna tworzony produkt, będzie bardziej samodzielny. 2. Dawać feedback na Przeglądzie Sprintu – występujesz tu trochę w roli interesariusza, czyli osoby zainteresowanej tym, co wytwarza zespół. Podobnie, jak w przypadku Refinementu, Twoja aktywność może tu przybierać różne formy i intensywność. Przede wszystkim zadawaj pytania dotyczące omawianego przyrostu np. aby lepiej zrozumieć jakiś jego aspekt lub aby zapoczątkować jakąś dyskusję poszerzającą kontekst spotkania. Z drugiej strony, możesz być także osobą, która będzie dawać informację zwrotną, zarówno członkom zespołu, jak i też innym interesariuszom. Ten feedback może dotyczyć efektywności samego Przeglądu Sprintu, przygotowania do niego, prowadzenia dyskusji i formy komunikacji interesariuszy z zespołem. Warto też pamiętać o pozytywnych aspektach, docenieniu wykonanej pracy i podziękowaniu za zaangażowanie. Jest to o tyle ważne, gdyż, sposób komunikowania się managera może modelować pewne zachowania wewnątrz zespołu, jak i na styku zespołu i interesariuszy. Manager może swoją postawą propagować i pokazywać zachowania wprowadzające dobrą atmosferę i ogólne standardy funkcjonowania zespołu. 3. Jak najczęściej zadawać pytanie: Jak mogę pomóc? – istotę tego pytania można zobaczyć, oglądając serial Szpital New Amsterdam, w którym pojawia się nowy manager. Jednym z głównych pytań, jakie zadaje, jest właśnie pytanie: Jak mogę pomóc? Widać tam, jak samo zadanie niby błahego pytania, otwiera ludzi i powoduje, że dzielą się tym, co im przeszkadza, utrudnia pracę i czego potrzebują. Oczywiście, musi być tu faktyczna intencja chęci pomocy i zainteresowanie odpowiedziami. Wówczas to pytanie ma ogromną moc, o której sami się też przekonaliśmy w naszej pracy managerskiej. Pokazuje też koncepcję roli managera jako osoby, która wspiera zespół w różnych kwestiach i przypomina zespołowi, że jest do jego dyspozycji. 4. Spotykać się regularnie z całym zespołem – służy to nie tylko przekazaniu informacji jednocześnie wszystkim,

Przygotowaliśmy kilka wskazówek, dzięki którym dowiesz się jak stworzyć zespół zarządzania zmianą w Twojej organizacji. Dowiesz się też, dlaczego taki zespół jest potrzebny i jakie są jego główne zadania. Porządny Agile · #090 – Tworzenie zespołu zarządzania zmianą Jednym z istotnych elementów procesu zmiany w organizacji jest powołanie zespołu odpowiedzialnego za zarządzanie tym procesem. Jak zbudować taki zespół i jakie rzeczy należy wziąć pod uwagę? Spis treści Jak zdefiniować zespół zarządzania zmianą?Dlaczego potrzebujemy zespół zarządzania zmianą?Główne zadania zespołu zarządzania zmianąNa co zwrócić uwagę ustalając skład zespołu zarządzania zmianą?Na co zwrócić uwagę konstruując zespół zarządzania zmianą?FAQ: Tworzenie zespołu zarządzania zmianą📄Transkrypcja podcastu „Tworzenie zespołu zarządzania zmianą” Ponieważ sami dosyć często jesteśmy zaangażowani w proces zmiany w różnych organizacjach, stąd też mamy duże doświadczenie w tej kwestii. W tym artykule podzielimy się z Tobą naszymi obserwacjami na temat zespołów zarządzających zmianą oraz kilkoma praktycznymi wskazówkami jak taki zespół stworzyć. Jak zdefiniować zespół zarządzania zmianą? Najprościej ujmując, zespół zarządzania zmianą jest zespołem ludzi, najczęściej menedżerów średniego i wyższego szczebla, którzy są odpowiedzialni za przeprowadzenie zmiany w organizacji. W kontekście Agile oznacza to przeprowadzenie transformacji zwinnej, uruchomienie zwinnych zespołów lub przeprowadzenie jakiejś reorganizacji. Może to być kolejny poziom jakiegoś pogłębienia zwinności w organizacji lub jakieś dopasowanie się wynikające ze zmian strategicznych, czy organizacyjnych. Oczywiście nie ma obowiązku formowania takiego zespołu, można zarządzać zmianą, wykorzystując już istniejące zespoły, czy departamenty odpowiedzialne za określone funkcje w organizacji. Jednakże istnienie zespołu zarządzania zmianą podnosi szansę na to, że zmiana będzie zarządzana w ułożony systemowy sposób.  Istotne jest, aby osoby wchodzące w skład tego zespołu, posiadały autorytet i sprawczość, która będzie pozwalała kształtować, wdrażać i podtrzymywać zmianę toczącą się w organizacji. Dlaczego potrzebujemy zespół zarządzania zmianą? Ponieważ każda zmiana, niezależnie od tego, co jest jej ostatecznym celem, jest zwykle bardzo złożonym i wieloetapowy procesem, przez co wymaga skupienia, zaangażowania i aktywności wielu osób jednocześnie przez dłuższy okres. Pozostawienie tego obszaru bez ustalonej odpowiedzialności za niego, zmniejsza szansę na to, że zmiana zostanie przeprowadzona w optymalny i sensowny sposób. Można powiedzieć, że powołanie takiego zespołu jest niejako czynnikiem zwiększającym szansę na uzyskanie oczekiwanego efektu, który określiliśmy na początku definiowania zmiany.  Do zarządzania zmianą mogą nie wystarczyć standardowe metody zarządzania organizacją, gdyż dopasowane są one raczej do utrzymania bieżącego stanu rzeczy i zajmowania się sprawami operacyjnymi. Zwykle niezbędne jest tu podejście systemowe z bardzo konsekwentnym dążeniem do tej zmiany, budowaniem poparcia, analizowania różnych opcji. Zarządzanie zmianą wiąże się najczęściej z wielowymiarową reorganizacją, zmianą procesu, a nawet zmianą ról poszczególnych osób w firmie. To jest na tyle głębokie i duże przedsięwzięcie, że po prostu regularnym cotygodniowy status z szefem albo w jakiś grupach, będzie niewystarczający.  Główne zadania zespołu zarządzania zmianą Gdy zespół zarządzania zmianą jest już stworzony, kolejnym krokiem powinno być stworzenie wizji i budowanie zrozumienia, dlaczego ta zmiana jest potrzebna w organizacji. Jest to niezbędne zarówno wewnątrz zespołu, jak i w ramach całej organizacji. Należy odpowiednio zakomunikować, dlaczego musimy się zmienić, dlaczego teraz, jak chcemy to zrobić, w jakim kierunku zmierzamy. To wszystko musi być zrozumiałe przez pracowników na wszystkich szczeblach zarządzania firmą. Kolejnym krokiem jest działalność operacyjna związana z implementacją wizji. Składa się na to wiele czynności, które należy ze sobą powiązać, wyciągnąć wnioski, zastanowić się, jakie powinny być kolejne kroki. Proces ten trwa dłuższy okres, ale jest to niezbędne, bo jak powszechnie wiadomo “wizja bez egzekucji to halucynacje”. Trzecim zadaniem dla zespołu zarządzania zmianą jest rozwiewanie wątpliwości związanych z tą zmianą. Zespół niejako staje się twarzą zmiany i wyjaśnia, udziela odpowiedzi i pokazuje przez własny przykład pewne zmiany. Nie da się tego zaplanować, można jedynie w czasie rzeczywistym odpowiednio reagować.  Na co zwrócić uwagę ustalając skład zespołu zarządzania zmianą? Budując zespół zarządzania zmianą pod uwagę powinniśmy wziąć kilka aspektów. Pierwszym z nich jest decyzyjność, gdyż z doświadczenia wiemy, że częstym powodem problemów lub nieudanych działań jest brak pełnej decyzyjności, która jest niezbędna do przeprowadzenia procesu zmiany. Dlatego należy zadać sobie pytanie czy członkowie zespołu mają realny wpływ na sposób fu

Refinement Backlogu Produktu to dość częsty obszar do poprawy w Zespołach Scrumowych. Usprawnianie go bywa problematyczne i nie każdy wie, kto i za co jest odpowiedzialny w tym procesie. Podpowiadamy jakie zadania mogą mieć Deweloperzy, Product Owner i Scrum Master w procesie Refinementu. Porządny Agile · #089 – Odpowiedzialności Zespołu Scrumowego na Refinemencie Jakie odpowiedzialności leżą po stronie Deweloperów, jakie u Product Ownera, a jakie u Scrum Mastera na etapie doskonalenia Backlogu Produktu? Spis treści Odpowiedzialności Deweloperów na RefinemencieOdpowiedzialności Product Ownera na RefinemencieOdpowiedzialności Scrum Mastera na RefinemencieOdpowiedzialności Zespołu Scrumowego na RefinemencieFAQ: Odpowiedzialności Zespołu Scrumowego na RefinemencieTranskrypcja podcastu „Odpowiedzialności Zespołu Scrumowego na Refinemencie” Odpowiedzialności Deweloperów na Refinemencie Deweloperzy przede wszystkim odpowiedzialni są za przygotowanie propozycji rozwiązań określonych potrzeb zawartych w Backlogu Produktu i artykułowanych przez Product Ownera. To nie Product Owner ma wiedzieć, jakie konkretnie ma być wytworzone rozwiązanie. W jego gestii leży przede wszystkim klarowne przedstawienie problemu i priorytetyzacja kolejności prac według wartości biznesowej. Zadaniem deweloperów jest też dogłębne poznanie zagadnienia i przemyślenie zasadności wdrażania różnych funkcjonalności. Zwłaszcza takich, które przychodzą jako pomysły od klientów czy interesariuszy. Zapoznanie się z zagadnieniem przez deweloperów może przynieść lepsze rozwiązania niż te, które zostały zaproponowane przez osoby mniej techniczne.  Kolejną odpowiedzialnością Deweloperów na Refinemencie jest komunikowanie szans i zagrożeń technologicznych. Chodzi tu o to, aby przedstawić plusy i minusy różnych rozwiązań. Przykładowo jedna opcja wydaje się szybka do wdrożenia, ale jest mało wydajna. Inne rozwiązanie może zająć więcej czasu, jednak być bardziej przyszłościowe i skalowalne na dodatkowe obszary biznesowe. Bardzo istotne jest to, aby Deweloperzy mieli postawę aktywną i brali udział w dyskusjach o różnych opcjach. Następną funkcją Deweloperów jest pomoc w podzieleniu elementów Backlogu Produktu na mniejsze części. Ich udział w tym jest istotny zwłaszcza wtedy, gdy aby dokonać sensownego podziału niezbędne jest zrozumienie możliwości jakie występują. Deweloperzy często najlepiej wiedzą, co ma sens wydzielić, gdzie będzie z takiego dzielenia korzyść, a gdzie tego zysku będzie mniej. Deweloperzy dzięki swojej wiedzy technicznej i bardzo dobrej znajomości produktu są często w stanie zaproponować bardziej sensowny podział. Wezmą pod uwagę np. wydajność, skalowalność czy ewentualne dalsze możliwości rozbudowy. Ostatnią odpowiedzialnością Deweloperów w procesie Refinementu jest ocena wielkości Backlogu Produktu. Może to dotyczyć oceny czasu pracy w godzinach, czy oceny w jednostkach relatywnych typu Story Pointy. Niektóre Zespołu godzą się na proste oceny, czy dany element jest wystarczająco mały, aby zmieścić się do Sprintu. Ta ocena wielkości jest potrzebna do określenia, ile Zespół jest w stanie zrealizować w trakcie Sprintu. Estymata bywa wykorzystywana do planowania pojedynczej iteracji i dłuższych horyzontów rozwoju.  Odpowiedzialności Product Ownera na Refinemencie Pierwszą odpowiedzialnością Product Ownera jest zapewnienie kontekstu biznesowego produktu. Dba o to, żeby osoby zaangażowane w Refinement dobrze rozumiały dlaczego i dla kogo budują produkt. Pomaga im też zrozumieć to, w jaki sposób firma chce osiągnąć określone kroki milowe. Ważne jest też, aby to zrozumienie było na bieżąco aktualizowane. Z czasem zespół coraz lepiej rozumie otoczenie biznesowe, a rolą PO pozostaje pilnowanie, aby nie stracić tego kontekstu z oczu. Ten kontekst biznesowy, o którym mówimy, może mieć kilka poziomów. Może to być kontekst całego produktu, czyli jaką PO ma wizję, po co buduje daną inicjatywę czy nowy produkt. Może to być także bardziej przyziemny poziom dotyczący pojedynczych drobnych zmian. Dlaczego potrzebne jest dodanie tego przycisku? Czemu klient nie jest zadowolony z obecnej funkcjonalności? Z jakich powodów konkretną rzecz trzeba poprawić? Niestety bywa, że ten szerszy kontekst jest pomijany i część osób w zespole może nie znać powodów realizacji zmiany.  Drugą funkcją Product Ownera przy Refinemencie Backlogu Produktu jest pomoc w zrozumieniu konsekwencji i niuansów biznesowych wybranych rozwiązań. To lustrzane odbicie szans i zagrożeń technologicznych, o których pisaliśmy w punkcie o odpowiedzialnościach Deweloperów. Deweloperzy mogą określić co jest bardziej lub mniej wydajnym rozwiązaniem. Product Owner może zwrócić uwagę, że np. skala użycia produktu będzie większa o 100%, bo planowana jest duża promocja lub uruchamiane jest nowe partnerstwo. W tym przypadku, zarówno Deweloperzy, jak i PO, mogą wymienić się różnymi perspektywami i dopowiedzieć założenia, a także przestrzec przed konsekwencja

Definicja Ukończenia – Definition of Done – jest ważnym zobowiązaniem scrumowym powiązanym z Przyrostem produktu. Tworzy ona przejrzystość, dzięki której wszyscy rozumieją jaką pracę trzeba wykonać. Porządny Agile · #088 – Definicja Ukończenia Ustalenie Definicji Ukończenia to zadanie Zespołu Scrumowego. W tym artykule opowiemy nie tylko o tym, co oznacza Definicja Ukończenia, ale podamy Ci przykłady jej elementów składowych oraz podzielimy się praktycznymi wskazówkami jak efektywnie stosować DoD w pracy. Spis treści Czym jest Definicji Ukończenia?Przykłady elementów składowych DoDWskazówki praktyczne przy stosowaniu Definicji UkończeniaFAQ: Definicja UkończeniaMateriały dodatkowe📄Transkrypcja podcastu „Definicja Ukończenia” Czym jest Definicji Ukończenia? Zgodnie z Przewodnikiem po Scrumie Definicja Ukończenia to formalny opis stanu przyrostu, w którym spełnia on kryteria jakościowe wymagane dla produktu. Konkretny przyrost powstaje, kiedy element Backlogu Produktu osiąga zgodność z Definition of Done.  Definicja Ukończenia tworzy przejrzystość. Powoduje, że wszyscy tak samo rozumieją, jaką pracę trzeba wykonać, żeby osiągnąć przyrost, który będzie ukończony.  W najnowszej wersji Przewodnika po Scrumie dodano bardzo ważne zastrzeżenie, że jeśli dany element Backlogu Produktu nie osiągnął stanu zgodnego z Definicją Ukończenia, nie może zostać nawet pokazany podczas przeglądu Sprintu. Odpowiedzialność za zdefiniowanie Definicji Ukończenia spoczywa na Zespole Scrumowym, a jeśli więcej zespołów korzysta z DoD, to powinny one umówić się na określony standard i wówczas żaden zespół nie może dostarczać swojej części produktu w niższym standardzie. Może za to dostarczać go w wyższym.  Jeśli organizacja formułuje pewne ograniczenia, oczekiwania, czy standardy dla zespołów, to powinny one przyjąć te oczekiwania jako część swojego Definition of Done. W celu podkreślenia istotności tego narzędzia przedstawimy Ci pewne analogie z życia codziennego. Pierwsza z nich jest powiązana z hobby, np. prace w ogrodzie. Gdy Kuba kosi trawnik, to oprócz samego skoszenia trawy i sprawienia, że jest ona krótsza, to musi on także zrobić po sobie porządek. Kosiarka nie może zostać na środku trawnika, kabel powinien być zwinięty, a trawa, która nie trafiła do pojemnika w kosiarce, zgrabiona i wyrzucona. Jeśli tego nie zrobi, to będzie to wyglądać nieestetycznie, a trawnik będzie zawalony składowymi koszenia. W momencie, gdy będzie chciał ponownie skosić trawnik, to może mieć problem ze znalezieniem np. kosiarki, bo ktoś inny schował ją w inne miejsce niż zazwyczaj.  Drugim przykładem, od Jacka, jest hobby związane z pracami w domowym warsztacie samochodowym. Pełni ją wydzielona strefa w garażu. Część rzeczy ma tam poukładane i wie, że np. klucze nasadowe znajdują się w określonych pojemnikach. Zdarza się tak, że kończy on swoje prace późno, ale ma ochotę jechać na przejażdżkę testową. Żeby było szybciej narzędzia, które używał, odkłada na bok, zamiast na swoje miejsce. I to właśnie będzie rodziło problemy w przyszłości, bo nie będzie wiedział, gdzie są poszczególne narzędzia. Dlatego częścią naprawy powinno być posprzątanie i odłożenie narzędzi tam, gdzie powinny się znajdować. Dzięki temu kolejnym razem nie będzie miał niespodzianek i nie będzie tracić czasu na szukanie narzędzi.  Te dwie analogie pokazują, że częścią pracy jest także doprowadzenie pewnych czynności do “dodatkowego” końca, czyli posprzątanie po sobie, poukładanie narzędzi.  Ostatnią analogią podzielił się mentor Kuby na początku jego pracy: „Wyobraź sobie, że podbijamy jakiś nowy teren, jesteśmy zdobywcami i wykonujemy konkretne kolejne kroki. Osiągamy pewną granicę terenu i my ten teren, który zdobywamy, umacniamy. Tworzymy zabudowania, tworzymy jakiś bastion, tworzymy mury i te mury już są nienaruszalne. Osiągamy ten stan i mamy gwarancję, że już ten etap osiągnęliśmy i w kolejnym kroku możemy znowu podbić kawałek terenu i znowu go umocnić”. Jest to poniekąd metafora ukończonych, kolejnych, kompletnych kroków. Jeśli działamy zgodnie z Definicją Ukończenia, to każdy kolejny krok jest właśnie w tym sensie umocniony. Nie musimy się cofać, nie musimy się martwić, nie musimy się zastanawiać, czy za nami nie zostało coś niedokończonego. Każdy krok, każdy kolejny kawałek produktu, jest już kompletny, skończony, w tym samym jednoznacznym, nienaruszonym standardzie. Przykłady elementów składowych DoD W skład Definicji Ukończenia mogą wchodzić: 1. Spełnione kryteria akceptacji Produkt, przyrost czy konkretny element Backlog Produktu jest skończony wtedy, gdy spełnione są kryteria akceptacji, które zostały sformułowane dla tego elementu. Czym są kryteria akceptacji? Można powiedzieć, że jest to unikatowa umowa mówiąca, po czym poznamy, że konkretny element z Backlogu Produktu został zrealizowany zgodnie z oczekiwaniami. Natomiast oczekiwanie, że kryteria akceptacji będą spełnione, jako część Definicji Uko

Planowanie sprawia dużo problemów w pracy zespołów. Zjawisko to widzimy bardzo często wśród zespołów, z którymi pracujemy. Na podstawie książki Jacka “Labirynty Scruma” przygotowaliśmy listę niezbędnych elementów porządnego planowania pracy zespołu. Uwzględnij je w swojej pracy, by była ona uporządkowana i natłok zadań nie sprawiał problemu. Porządny Agile · #087 – Co uwzględnić w planowaniu zespołowym? Pracując z zespołami zwinnymi częstym problemem, z jakim się spotykamy, są trudności z planowaniem. Postanowiliśmy przyjrzeć się bliżej temu tematowi, bo jest to bardzo istotny element pracy zwinnej, gdyż wpływa na kolejne jej etapy.  Spis treści Niezbędne elementy porządnego planowania pracy zespołuPlanowanie zespołowe – dodatkowe przemyśleniaFAQ: Co uwzględnić w planowaniu zespołowym?📄Transkrypcja podcastu „Co uwzględnić w planowaniu zespołowym?” Przede wszystkim, źle zaplanowana praca wpływa na mało efektywną współpracę, brak realizacji celów Sprintów oraz problemy z terminami.  W tym arykule skupimy się omówieniu niezbędnych elementów porządnego planowania pracy. Elementy te pochodzą z książki Jacka “Labirynty Scruma”, w której opisuje on konkretne rozwiązania na najczęstsze problemy pracy w Scrumie. My listę tę uzupełniliśmy o naszą aktualną wiedzę i nowe doświadczenia. Niezbędne elementy porządnego planowania pracy zespołu 1. Dostępność członków Zespołu Zwykle jest tak, że w większych zespołach i dłuższych (np. dwutygodniowych) iteracjach, prawdopodobnie ktoś z zespołu będzie częściowo lub całkowicie niedostępny. Przyczyn może być wiele, np. urlop, zaplanowane szkolenie, wizyta u klienta. Dlatego warto wziąć to pod uwagę podczas planowania i ustalić dostępność poszczególnych członków. To będzie mocno rzutować na liczbę zadań, jakie może wykonać zespół i ogólnie mówiąc na jego przepustowość.  Znaczenie mogą mieć nawet 2 godziny nieobecności, bo jednego nie będzie 2 godziny, kogoś innego pół dnia, a jeszcze inna osoba będzie w 2-dniowej delegacji u klienta. W efekcie nie mamy pełnych 2 tygodni do wykorzystania. W praktyce sprawdzenie dostępności możemy przeprowadzić w tabelce w Excelu czy w kalendarzu, aby klarownie zwizualizować wszystko. 2. Zależności zewnętrzne Zależności zewnętrzne są to wszystkie tematy, które znajdują się poza obszarem zespołu i nie do końca ma on na nie wpływ. Może to dotyczyć np. kompetencji, których nie mamy wewnątrz a potrzebujemy ich w konkretnej iteracji czy Sprincie. Mogą to być także dostawcy zewnętrzni różnego rodzaju systemów czy API. Innymi słowy, są to wszystkie te rzeczy, które nie leżą w ramach naszych kompetencji i na które nie mamy bezpośredniego wpływu, jednak nasza praca od nich zależy. Dlatego musimy wziąć je pod uwagę podczas planowania i tak ułożyć sobie plan, żeby jak najsprawniej przebiegała praca i nie być zaskoczonym, że na coś musimy dłużej czekać.  3. Kolejność wykonywania pracy Rekomendujemy tu wspólną refleksję nad tym, w jakiej kolejności wykonamy działania, które mamy do zrobienia. Zanim zaczniemy zapełniać pracą zasoby czasowe poszczególnych osób, popatrzmy bardziej przez perspektywę, jak jako zespół chcemy wykonać kolejne elementy, które są do realizacji w ramach danej iteracji.  Przykładowo Zespół Scrumowy mógłby zacząć od Celu Sprintu. Gdy Cel Sprintu będzie zrealizowany, można się zabrać za kolejne tematy, które są zaplanowane w tym Sprincie. Unikniemy wtedy sytuacji, że najważniejsza rzecz nie zostanie zrealizowana, bo przykryją ją mniej istotne na chwilę obecną tematy. To tak jak podczas pakowania torby na wyjazd, bez zaplanowania kolejności wkładania rzeczy, może się zdarzyć tak, że butelkę z wodą, którą powinniśmy mieć pod ręką, wrzucimy do torby jako pierwszą i będzie przykryta innymi, niepotrzebnymi w podczas podróży rzeczami.  4. Zależności wewnętrzne Mówiliśmy o zależnościach zewnętrznych zespołu. Podobny problem może się pojawić również w ramach zależności wewnętrznych. Częstą sytuacją, z jaką się spotykamy, jest zależność części back-end’owej od części front-end’owej. Pojawiają się tam pytania dotyczące tego, kto powinien rozpocząć pracę, od czego zacząć i jak. Jeśli zależy nam, aby rozwój produktu odbywał się równocześnie na wszystkich warstwach i każdy Sprint kończył się sensownym przyrostem, to należałoby się zastanowić głębiej nad tymi zależnościami i poukładać pracę, tak aby nie było przestojów.  Innym przykładem takich zależności spoza świata IT to przykład, gdy grafik musi najpierw coś zaprojektować, aby osoba z marketingu mogła tego użyć w działaniach promocyjnych.  Dlatego w toku planowania trzeba po prostu przemyśleć, jakie mamy zależności wewnętrzne i uwzględnić je w planie, aby uniknąć opóźnień w pracy zespołu. Te opóźnienia mogą pojawić się zwłaszcza wtedy, gdy zależności w zespole są bardzo silne i konkretne zadania muszą następować jedno po drugim, w tej właśnie kolejności.  5. Dostępne kompetencje członków Zespołu Z zależnościami wewnętrzny

Ważne jest, żeby zespół miał zdolność do ewaluacji wrzutek i podjęcia merytorycznej dyskusji z interesariuszami. Wrzutki to normalne zjawisko w trakcie Sprintu. Są to nieplanowane prace niebędące rzeczami krytycznymi czy awariami. Jak zatem zapanować nad zadaniami, które się nagle pojawiają? Skorzystaj z naszych kilku rozwiązań, żeby sobie z tym poradzić. Porządny Agile · #086 – Jak radzić sobie z wrzutkami w Scrumie? Wrzutki, znamy je wszyscy. Są one normalnym zjawiskiem w trakcie trwania Sprintu. Dlatego warto nauczyć się nimi zarządzać i rozmawiać z interesariuszami na ich temat. Nieplanowane zadania, czyli wrzutki, otrzymujemy od różnych osób w trakcie trwania Sprintu. Nie są one awariami ani nie są krytyczne dla poprawnego działania usługi, produktu czy ogólnie firmy, jednak dla zlecającego często mają status pilnych i na wczoraj. Spis treści Jak radzić sobie z wrzutkami w Scrumie?5 sposobów na wrzutki w Scrumie:FAQ: Jak radzić sobie z wrzutkami w Scrumie?📄Transkrypcja podcastu „Jak radzić sobie z wrzutkami w Scrumie?” W tym artykule dzielimy się z Tobą naszymi wskazówkami jak zapanować nad zadaniami, które pojawiają się nagle i potrafią zaburzyć plan Sprintu. Jak radzić sobie z wrzutkami w Scrumie? Przede wszystkim przestrzegamy Cię przed skrajnościami. Z jednej strony nie przyjmuj wszystkich wrzutek, jak leci, pamiętaj o Celu Sprintu i nie sabotuj jego osiągnięcia przez realizowanie nieplanowanych zadań. Podejście odwrotne, czyli odrzucanie każdej wrzutki, też nie jest dobrym podejściem. Nie zasłaniajcie się Celem Sprintu, odmawiając interesariuszom. Jest to z jednej strony niezgodne z samą definicją Scruma (czyli elastyczne podejście do pracy, reagowanie na zmiany), z drugiej strony jest to niepragmatyczne. Kluczową umiejętnością zespołu jest zdolność do oceny konkretnej wrzutki i podjęcie merytorycznej dyskusji z interesariuszami, która powinna się zakończyć przemyślaną decyzją uwzględniającą potrzeby i cele obu stron. Nim przejdziemy do konkretnych wskazówek jak radzić sobie z wrzutkami, to chcemy zaznaczyć, że nie będziemy tu poruszać sytuacji, gdy wrzutki są nagminne, a ich podłoże ma problem systemowy dotyczący całej organizacji. Tu należy dokonać głębszej analizy i przeprowadzenia bardziej złożonych usprawnień. 5 sposobów na wrzutki w Scrumie: Przetestuj krótsze SprintyW tym podejściu nie zajmujemy się wrzutką od razu, a jednocześnie oferujemy interesariuszom większą responsywność i stosunkowo krótki czas oczekiwania na zaopiekowanie się nowym zadaniem. Po prostu częstotliwość sesji planowania się zwiększa. Wyobraźmy sobie, że pracujemy w Sprincie dwutygodniowym. Wystartowaliśmy go w poniedziałek, a już w środę pojawia się interesariusz z pilnym tematem do zrealizowania. Dzięki krótszym Sprintom nie musi on czekać aż 1,5 tygodnia na nowy Sprint, tylko 2 dni. My z kolei nie burzymy planu Sprintu. Tygodniowy Sprint? Tak. Pamiętaj, że Przewodnik po Scrumie nie narzuca przeprowadzania dwutygodniowych Sprintów. Takie podejście jest bardzo popularne, jednak nie musi się sprawdzać w każdym zespole. Krótsze Sprinty mogą w efekcie sprawić, że wrzutki przestaną być na tyle pilne, żeby interesariusz nie mógł poczekać kilku dni do nowego planowania.   Zaplanuj buforJeśli w naszych Sprintach wrzutki pojawiają się od czasu do czasu, to dobrą praktyką jest zaplanowanie sobie przestrzeni czasowej na takie dodatkowe zadania. Czyli nie jesteśmy zaplanowani na 100%. Dzięki temu fakt, że w środku Sprintu pojawia się wrzutka, nie powoduje np. zawalenia Celu sprintu. Wielkość bufora określ bazując na danych historycznych, patrząc jak często wrzutki się pojawiały, jak duże były i ile czasu zajmowały zespołowi. A jeśli nie posiadacie danych historycznych, to po prostu testujcie różne bufory. Policz Koszt Opóźnienia (Cost of delay)W podejściu tym zastanawiamy się, czy opóźnienie realizacji tego zadania będzie nas kosztować. Jeśli tak, to ile będzie kosztować to opóźnienie. Przykładowo, rozwijamy jakąś aplikację e-commerce’ową. Przestała działać możliwość udzielania kredytu osobom, które chcą kupić coś na naszej stronie. Aby podjąć decyzję, czy powinniśmy od razu zająć się tą sytuacją, należałoby się zastanowić, jak dużo pieniędzy firma straci w momencie, kiedy przez na przykład trzy dni nie będziemy w stanie tych rat udzielać. Dodatkowo warto byłoby tę potencjalną stratę zestawić z kosztem elementów, które były pierwotnie zaplanowane. Co będzie bardziej kosztowne dla organizacji? Mnogość możliwych scenariuszy jest tu ogromna. Jakaś drobna rzecz i kilka dni roboczych całego zespołu, może czasami robić gigantyczny wynik, a wtedy ważniejsze może będzie zareagowanie na to. Oczywiście zakładamy tu, że mamy miary i wszystko jest policzone, a nie, że każdy wymyśla swoje liczby, które nie są poparte czymkolwiek.  Wymieniaj elementy 1 za 1 (Changes for free)Jesteśmy z tym ok, że od czasu do czasu pojawiają się wrzutki. Mamy jednak w Zespole taką zasadę, że jeśli coś nowego wchodzi do Sprintu,

Znalezienie i zrozumienie prawdziwej potrzeby klienta jest jednym z podstawowych elementów procesu tworzenia udanych produktów. Z artykułu dowiesz się jakie mogą być powody, dla których zespoły nie docierają do potrzeb kleintów. Przeczytasz też, dlaczego warto do tego dążyć oraz jak to zrobić w praktyce. Porządny Agile · #085 – Znajdowanie prawdziwej potrzeby klienta Spis treści Przykłady z życia, kiedy zespoły nie zgłębiają prawdziwej potrzeby klientaPotencjalne powody dlaczego zespoły nie szukają prawdziwej potrzeby klientaDlaczego warto dążyć do zidentyfikowania prawdziwej potrzeby klienta?Jak poprawić identyfikację prawdziwej potrzeby klienta?Kiedy nasze porady mogą okazać się nietrafione?FAQ: Znajdowanie prawdziwej potrzeby klienta📄Transkrypcja podcastu „Znajdowanie prawdziwej potrzeby klienta” O zgłębianiu prawdziwej potrzeby klienta pisaliśmy już w artykule o tym, jak przeprowadzać porządnie Refinement Backlogu Produktu. Poniższy artykuł pogłębia i poszerza ten wątek. Przykłady z życia, kiedy zespoły nie zgłębiają prawdziwej potrzeby klienta Przykład pierwszy: ubezpieczenie komunikacyjne Wyobraź sobie zespół, który rozwija system do zarządzania ubezpieczeń komunikacyjnych. Zespół miał dodać do systemu flagę. Otrzymał konkretne informacje dotyczące tego w jakiej usłudze, w jakim polu, o jakiej nazwie, należy dodać jaką flagę i jakie wartości ma ta flaga przyjmować. Zespół długo dyskutował o szczegółach rozwiązania tego zadania, nie wiedząc za bardzo jaki był kontekst i powód jego wdrożenia. W tym konkretnym przypadku ktoś w końcu zapytał, po co w zasadzie mają ustawiać tę flagę przy tym ubezpieczeniu komunikacyjnym. Okazało się, że firma chce zaoferować bardzo korzystne rozwiązanie, unikalne na rynku, które będzie oznaczało, że te ubezpieczenia będą miały atrakcyjny pakiet, w którym kierowcy będą mieli zarówno autocasco jak i assistance. Stąd pojawiła się potrzeba odzwierciedlenia tego w systemie, że jest możliwość skorzystania z jakiegoś ciekawego, odrębnego ubezpieczenia. Natomiast istniał dramatyczny rozdźwięk między „ustawcie flagę w bazie”, a tym, że „chcemy zrobić unikalne ubezpieczenie i potrzebujemy je mieć w jakiś sposób widoczne w systemie”. Dopiero gdy zespół dowiedział się, po co ma zrealizować to zadanie, tak naprawdę zaczęła się sensowna i głęboka rozmowa o tym, jak do niego podejść i je zrealizować.  Przykład drugi: wyszukiwarka w systemie Do zespołu, w którym pracował Jacek, przyszedł Product Owner. Zaczął opowieść, z której wynikało, że w konkretnym miejscu systemu potrzebuje wyszukiwarkę. Chciał uzyskać możliwość wyszukiwania parametrów, przypiętych do produktów, sprzedawanych na platformie e-commerce, którą rozwijał. Rozpoczęła się długa rozmowa o tej wyszukiwarce: jak często odświeżać rezultaty wyszukiwania, jak często ją indeksować, czy ma tam być możliwe zaawansowane wyszukiwanie. Dopiero po pewnym czasie zespół zaczął dociekać, po co Product Ownerowi tak naprawdę jest potrzebna wyszukiwarka. Od słowa do słowa okazało się, że tych elementów, które chciał wyszukiwać, wcale nie było tak dużo. Kiedy zespół zrozumiał, z jakim problemem przyszedł Product Owner, to zaproponował zupełnie inne rozwiązanie (paginację), które można było zaimplementować w pół dnia, zamiast budować skomplikowaną wyszukiwarkę. Oba przykłady pokazują, że należy zadawać pytania, trzeba próbować zrozumieć potrzeby, bo zwykle prowadzi do zespoły do lepszych rozwiązań, nierzadko tańszych i bardziej dopasowanych do potrzeb klientów lub użytkowników.  Potencjalne powody dlaczego zespoły nie szukają prawdziwej potrzeby klienta Bazując na naszym doświadczeniu, przygotowaliśmy 6 najczęstszych powodów pomijania etapu zrozumienia prawdziwej potrzeby klienta: “Nikt nie powiedział, że możemy pytać” – W zespole brak jest świadomości, że mogą zadawać pytania i pogłębiać swoje zrozumienie tematu. Działają automatycznie, dostają informacje, co mają zrobić i to robią. “Nie wolno nam” – Zespół jest ustawiony w pozycji, w której próba zadawania pogłębiających pytań – nawet otwartych, nawet bardzo grzecznie wypowiedzianych – jest niewskazana. Jeśli nawet nie jest to powiedziane wprost, to reakcje na te pytania powodują, że zespołowi się odechciewa ponownie pytać. “Mamy dużo funkcji do zbudowania, nie ma czasu” – Presja czasu i ilość pracy oczekującej na wykonanie jest tak duża, że najsensowniejszym rozwiązaniem wydaje się po prostu to robić, a nie zadawać pytania, które zajmą dodatkowy czas. “My tu nie jesteśmy od myślenia” – Zespół ma poczucie, że jest od robienia rzeczy, a od myślenia jest ktoś inny. Ten ktoś ma obraz całości, ktoś to wymyślił, no i pewnie ma rację. Zespół nie czuje się kompetentny, żeby to kwestionować. Doprowadza to do spłycenia roli, np. programistów do roli klepaczy kodu. “Nie wiemy jak to zrobić” – W zespole brakuje kompetencji na poziomie zadawania pytań, facylitacji rozmowy czy wizualizacji pracy do wykonania, ale też anali

Nie wiesz jak dalej się usprawniać? Wydaje Ci się, że nic więcej nie da się już zrobić lepiej? Mamy dla Ciebie kilka pomysłów, które możesz wypróbować, by dalej się usprawniać i przełamać założenie o braku możliwości lepszej pracy. Nie widzieliśmy do tej pory żadnego zespołu, który nie miałby czegoś do ulepszenia. Co więcej, nawet najlepsze zespoły wciąż dalej się usprawniają. Porządny Agile · #084 „Nie mamy już co usprawniać” Zespoły, które faktycznie zbliżają się do sytuacji, w której teoretycznie wszystko jest usprawnione, nie będą o tym głośno mówić. Dotarły do tego momentu dzięki ciągłym poszukiwaniom usprawnień i eksperymentom. Stąd też dalej będą to robić, nawet jeśli na pierwszy rzut oka nie widzą, co jeszcze mogłyby usprawnić. Te najlepsze zespoły nadal się usprawniają.  Jeśli w Twoim Zespole pojawiło się przekonanie, że stanęliście w miejscu, bo wdrożyliście już wszystkie możliwe usprawnienia, to zapraszamy do przeczytania tego artykułu. O czym wspominamy? Sprawdź spis treści: Spis treści “Nie mamy już co usprawniać” – skąd takie przekonanie?Nasze wskazówki dla Zespołów, które nie widzą potrzeby dalszego usprawniania sięFAQ: „Nie mamy już co usprawniać”📄Transkrypcja podcastu „Nie mamy już co usprawniać” “Nie mamy już co usprawniać” – skąd takie przekonanie? 1. Brak Retrospektyw Pierwszą, trochę oczywistą przyczyną takiej postawy jest to, że zespół po prostu nie realizuje spotkań usprawniających, czyli Retrospektyw Sprintu. Możemy mieć tu do czynienia z całkowitym brakiem jakichkolwiek czynności, które przypominałyby Retrospektywę, lub też robienie tego tak rzadko, że właściwie trudno mówić o jakichkolwiek ustaleniach czy wdrażanych usprawnieniach. 2. Retrospektywy nie mają struktury W tym przypadku Retrospektywy co prawda odbywają się, jednak są to spotkania bez określonej struktury i tylko nazwa nawiązuje do czynności usprawniających. Przypomina to chaotyczną wymianę zdań i pomysłów, wymieszaną z problemami i skargami. I na tym się kończy. 3. Ustalone usprawnienia nie są realizowane W tej sytuacji, pomimo przeprowadzonej Retrospektywy i wspólnych ustaleń na temat wdrożenia konkretnych usprawnień, nie są one realizowane. W efekcie nie ma namacalnych rezultatów i zmian. 4. Brak nazywania rzeczy po imieniu Członkowie zespołu nie mówią sobie, jak jest, nie mierzą się z prawdą, nie umieją nazwać tego, co widzą. Szczególnie trudna sytuacja będzie wtedy, gdy w zespole brak jest otwartości i transparentności odnośnie tego, jak wygląda współpraca, procesy i narzędzia. 5. Brak rozmów na trudne tematy W zespole poruszane są tylko tematy bezpieczne, a trudne sprawy są przemilczane, nie są wyciągane na forum zespołu. Oczywiście to, czym jest ta trudna sprawa, jest bardzo zależne od kontekstu danego zespołu. 6. Brak wsparcia organizacji Mamy tu na myśli sytuację, w której zespół całkiem nieźle przeprowadza Retrospektywy, rozmawia o usprawnieniach i ustala jakieś akcje. Problem pojawia się, jeśli te działania usprawnieniowe wymagają zmian poza zespołem, czyli np. w ogólnofirmowych procesach czy strukturze organizacji. Jeśli menedżerowie nie wspierają lub wręcz utrudniają realizację ustalonych pomysłów usprawnieniowych, to Zespół może mieć poczucie, że nie ma co usprawniać. To, co wymaga usprawnienia, jest poza ich możliwościami, a innych pomysłów nie mają. To są tylko przykładowe powody postawy “nie mamy już co usprawniać”, w rzeczywistości może być ich o wiele więcej. Chcemy zwrócić Twoją uwagę na fakt, że już sam taki komunikat od Zespołu to zaproszenie do rozmowy. Sensowne będzie podchwycenie tego wątku i przedyskutowanie z wszystkimi, dlaczego takie przekonanie pojawiło się w zespole. To może być taki punkt przełomowy i powrót do działań usprawniających. Nasze wskazówki dla Zespołów, które nie widzą potrzeby dalszego usprawniania się 1. Rób porządną Retrospektywę Najprostsza i najszybsza do wdrożenia porada to: zacznij realizować porządną Retrospektywę. Należy zadbać, aby odbywała się ona regularnie, miała ustaloną strukturę, a to, co zostanie na niej ustalone, powinno było faktycznie wykonane. Dobrze, aby spotkania te były moderowane (idealnie nadaje się do tego Scrum Master), aby był czas na zrozumienie przyczyn problemów i żeby Zespół czuł się dobrze poprowadzony oraz miał otwartość do rozmów. Sprawdź nasz materiał na temat tego, jak powinna wyglądać porządna Retrospektywa Sprintu, zobacz też, czy pomocny nie będzie w twoim przypadku nasz płatny webinar o Retrospektywie Sprintu. 2. Zrób Retrospektywę inaczej niż zazwyczaj Testowanie różnych technik przeprowadzania Retrospektywy pozwala znaleźć tę, która będzie najlepiej odpowiadać Zespołowi i dzięki temu będzie on chętniej brał udział w tych spotkaniach.  W ramach tych testów możesz sprawdzać różne struktury prowadzenia Retrospektywy, ale także zmienić miejsce, w jakim spotkania się odbywają (np. w restauracji, a jak jest ciepło to organizować je na trawniku lub w parku). Z kolei, jeśli typowe Retrospektywy w twoim

Częsty problem, jaki widzimy w zespołach, to jednoczesne realizowanie wielu zadań. Członkowie zespołu zaczynają kolejne zadania, nie kończąc rozpoczętych, co generuje problemy. Jak zatem można zmierzyć się z problemem niekończenia już rozpoczętych prac? Mamy kilka rad dla zespołów oraz osób zarządzających zespołami. Porządny Agile · #083 – Zacznij kończyć, przestań zaczynać Z doświadczenia wiemy, że równoległa realizacja wielu wątków wpływa negatywnie na wiele aspektów. Po części temat ten poruszaliśmy już w materiale „Mamy zbyt wiele projektów i co z tym zrobić?”. Tam skupiliśmy się na poziomie wielu projektów w całej organizacji. Ten artykuł natomiast będzie dotyczył pracy pojedynczego zespołu i pracy indywidualnej w jego ramach.  Spis treści Jak kończyć rozpoczętą pracę – rady dla zespołówJak kończyć rozpoczętą pracę – rady dla managerów i liderówFAQ: Zacznij kończyć, przestań zaczynać📄Transkrypcja podcastu „Zacznij kończyć, przestań zaczynać” Jak kończyć rozpoczętą pracę – rady dla zespołów 1.  Dziel pracę na mniejsze kawałki.  O dzieleniu pracy na mniejsze kawałki rozpisaliśmy się w materiale Dlaczego warto dzielić pracę na małe części. Jest to jedno z głównych rozwiązań problemu z rozpoczynaniem nowych tematów jeszcze przed zakończeniem tych, nad którymi aktualnie pracujemy.  Dlaczego? Praca, której zakres jest zbyt duży, często trwa długo i powoduje zniecierpliwienie np. osób spoza zespołu. Czekają oni na swoje zlecenia i naciskają, aby zacząć nowe tematy, które za długo znajdują się już w kolejce. Duże kawałki pracy często też utykają z różnych powodów. Przyczyn może być wiele, a najprostszym rozwiązaniem jest dzielenie pracy na mniejsze kawałki. Dzięki temu jest szansa, że skończysz ją w krótszym czasie i będziesz móc zająć się kolejnym tematem.  2. Planuj jeden konkretny krok.  W Zespołach Scrumowych najczęściej Product Owner określa, czym zajmuje się zespół i planuje konkretne cele. Problem pojawia się wtedy, gdy ten cel nie jest pojedynczym celem, a stanowi tzw. złożony wielocel. Zamiast jednego konkretnego Celu Sprintu, zespół ma kilka celów. Zamiast jednej najważniejszej rzeczy, ma kilka równie ważnych rzeczy do wykonania. I zamiast skupiać się na zrobieniu jednej rzeczy, ale porządnie i do końca, już od samego początku Zespół rozdrabnia się na kilka tematów.  Nasza rada brzmi: rób wszystko, aby skupiać się na konkretnej jednej rzeczy. Przy próbie złapania wielu srok za ogon najczęściej pojawia się właśnie problem z trudnością zamykania zadań.  3. Zdefiniuj swój proces pracy i zadbaj o płynność jego przepływu.  Spotykamy się też z sytuacją, w której zespół ma problem z kończeniem pracy, ponieważ nie do końca panuje nad swoim procesem. W tym procesie są różnego typu przestoje i niejasności, brak w nim płynności pracy i dążenia do kończenia zadań.  W praktyce chodzi o to, by całościowo spojrzeć na proces pracy w zespole. Zwróć uwagę, czy są w nim jakieś momenty, gdy pojawiają się spowolnienia lub praca całkowicie utyka w jednym punkcie. Co robicie w takich sytuacjach? Czy podejmujecie jako zespół decyzję, aby zająć się czymś, zamiast spróbować zawalczyć o to, żeby ten proces trochę upłynnić?  Bardzo pomocne w procesie definiowania procesu pracy i wyłapywania problematycznych momentów są wszelkiego rodzaju formy wizualizacji. Dzięki temu dostajesz wsparcie narzędziowe w dostrzeżeniu zjawisk, które w innym przypadku by umknęły.  4. Kończ otwarte zadania.  Zachęcamy do spojrzenia z lotu ptaka na to, czym się aktualnie zajmuje Twój zespół. Na tej bazie spróbuj ocenić co jesteście w stanie skończyć najszybciej. Domknięcie zadań w oczywisty sposób pomoże zmniejszyć liczbę pootwieranych wątków.  Warto wypracować sobie, najlepiej w ramach całego zespołu, nawyk domykania tematów. Bo sztuką nie jest mieć przez cały Sprint mnóstwo pootwieranych zadań i rozproszenie uwagi pomiędzy nie, a dopiero pod koniec Sprintu dopychanie ich do końca. Sztuką jest takie flow pracy, aby mieć jak najmniej na zadań w toku. Oznacz to brak konieczności przełączania się pomiędzy zadaniami i skupienie się na jednym temacie. Przykładowo, na Planowaniu Sprintu możesz zacząć od zaplanowania wykonania tych zadań, które nie zostały ukończone w poprzednim Sprincie, zanim zaczniesz planować pracę nowych tematów. Zwiększa to szanse, że te rozgrzebane już prace, zostaną dokończone. Możesz też zmienić formę Waszych Stand-upów / Daily. Najbardziej popularne formuły tych spotkań przebiegają tak, że kolejne osoby z zespołu opowiadają, czym się zajmowały wczoraj, co będą robić dzisiaj. Zamiast tego możliwe jest przechodzenie po zadaniach, które są najbliżej końca. Wspierającym to dobrym pomysłem jest wyświetlenie wizualizacji otwartych zadań – np. w postaci tablicy. Dzięki temu zespół przechodzi z myślenia „co robią osoby w zespole” na myślenie „które zadanie jest najbliżej końca” i szybkie ustalenie które

Jak budować autorytet Scrum Mastera w zespole? Spojrzeliśmy na temat z dwóch poziomów. Po pierwsze, jak manager Scrum Mastera może pomóc mu w budowaniu autorytetu. Po drugie, na co powinien zwrócić uwagę w pracy Scrum Mastera. Oczywiście nie musisz być liderem, żeby odsłuchać ten odcinek. Przygotowaliśmy sporo porad, z których możesz skorzystać jako Scrum Master czy Agile Coach w swojej codziennej pracy. Porządny Agile · #082 – Budowanie autorytetu Scrum Mastera Jak zbudować autorytet Scrum Mastera w zespole? Jak będąc jego przełożony, wesprzeć Scrum Mastera w tym zadaniu. Na co zwracać uwagę w jego rozwoju, aby ten autorytet wzmocnić. Spis treści Budowanie autorytetu Scrum Mastera – jak wspomóc w tym pracownika? Utrzymanie autorytetu Scrum Mastera – jak lider może tu pomóc?FAQ: Budowanie autorytetu Scrum Mastera📄Transkrypcja podcastu „Budowanie autorytetu Scrum Mastera” W tym artykule skupimy się właśnie na budowaniu autorytetu Scrum Mastera, jednak nie od strony samego pracownika, a jego menedżera czy lidera. Zatem artykuł ten dedykujemy głównie  do liderów, menedżerów, osób, które w ramach swojej struktury organizacyjnej zarządzają Scrum Masterami. Oczywiście, dużo wskazówek i porad znajdą tu także osoby pracujące na stanowisku Agile Coacha lub właśnie Scrum Mastera. Artykuł ten składa się z 2 części: w pierwszej części  powiemy o tym, co możesz zrobić, żeby pomóc budować autorytet Scrum Mastera w organizacji,  w drugiej części podpowiemy na co, warto zwracać uwagę, żeby Scrum Master utrzymał ten autorytet na dłuższy czas. Budowanie autorytetu Scrum Mastera – jak wspomóc w tym pracownika?  1. Zakontraktuj się ze Scrum Masterem  Umów się ze Scrum Masterem, jakie zadania będzie on realizował w ramach organizacji. Jest to bardzo istotne, gdyż rola Scrum Mastera w różnych firmach może oznaczać różne odpowiedzialności. Czasem jest to trochę bardziej Project Manager, czasem jest  to osoba, która skupia się wyłącznie na pracy zespołu. Dlatego Scrum Master musi być świadomy, czego od niego się oczekuje w Waszej firmie. Dobrze też, aby wiedział, co nie należy do jego obowiązków. To pomoże uniknąć rozczarowań po obu stronach. Poinformuj go też, na jakie wsparcie od Ciebie może liczyć, a gdzie leżą granice tego wsparcia. Jakie rzeczy będziecie wykonywać wspólnie, a w których obszarach oczekujesz od niego pełnej samodzielności. 2. Wprowadź Scrum Mastera do zespołu Po ustaleniu kontraktu ze Scrum Masterem, jako lider czy menedżer zespołu, Twoim zadaniem jest przedstawienie Scrum Mastera zespołowi i całej organizacji. Powinni wiedzieć, co należy do jego obowiązków, za co jest odpowiedzialny i czego mogę od niego oczekiwać. To pomoże wszystkim stronom lepiej współpracować. Scrum Master zostanie wprowadzony do zespołu, a jego rola będzie lepiej zrozumiana przez członków zespołu, natomiast ci członkowie nie będą czuć się zagubieni w roli, jaką ta nowa osoba pełni, za co odpowiada. 3. Wprowadź Scrum Mastera do struktury organizacyjnej  Kolejny krok to wprowadzenie Scrum Mastera do struktury organizacyjnej firmy. Pracownicy, a nawet sam zarząd, mogę nie wiedzieć co to za rola i dlaczego jest ważna w organizacji. Stąd ważne jest zakomunikowanie, za co ta konkretna osoba odpowiada, czego można się spodziewać i oczekiwać.  Pomocne może być także zabieranie Scrum Mastera na ważne spotkania i włączanie w różne inicjatywy. Automatycznie taka osoba będzie kojarzona z pewnym poziomem zarządzania, pewnym poziomem podejmowania decyzji i usprawniania organizacji. Jeśli Scrum Master jest nowym pracownikiem, to będzie to dla niego też ogromne ułatwienie w poznaniu i zrozumieniu struktury organizacji na start. 4. Oczekuj udziału w transformacji Pomocne w budowaniu autorytetu może być także oczekiwanie od Scrum Mastera udziału w zmianach w organizacji. Oczywiście, pamiętaj aby zakomunikować wszystkim, że Scrum Master jest aktywnym ogniwem transformacji organizacji i powinien brać w niej udział.  Piszemy o tym, bo wciąż jeszcze spotykamy się z takim błędnym przekonaniem, że rola Scrum Mastera jest kojarzona z działaniami po albo obok transformacji. Nie traktujmy Scrum Masterów jako tylko osoby od zespołu. 5. Nie rób rzeczy za Scrum Mastera To może wydawać się oczywiste, ale wolimy o tym przypomnieć: nie wyręczaj Scrum Mastera w jego obowiązkach. Nie tylko dołoży Ci to pracy, ale i będzie obniżać jego autorytet. Przykładowo, jeśli Scrum Master dopiero dołączył do organizacji i ma on przeprowadzić szkolenie dla menedżerów, to zamiast wyręczać go w tym zadaniu, lepszym podejściem będzie pomoc w przygotowaniu się do spotkania. Podpowiedz mu czego może się spodziewać, jakie pytania mogą paść, na co zwrócić uwagę przy przygotowywaniu prezentacji. Jeśli pojawią się obawa czy Scrum Master jest za młody lub za mało doświadczony, aby podjąć się jakiegoś zadania to dobrym podejściem jest każdorazowe zastanowienie się czy nie obniżymy jego autorytetu przez odsunięc

Nie wiesz co zrobić, gdy elementy Backlogu Produktu są za duże? Najczęściej można je podzielić i to tym będzie dzisiejszy odcinek. Wybraliśmy najważniejsze naszym zdaniem metody przydatne do dzielenia i przedstawiamy kilka refleksji związanych z tym tematem. Możesz wykorzystać polecane przez nas sposoby, by dzielić User Stories, feature’y i wszystko to, co jest kawałkiem produktu do wykonania. Managerowie natomiast dostaną od nas wskazówki, czego mogą oczekiwać w kontekście dzielenia produktu od zespołów. Porządny Agile · #081 Dzielenie elementów Backlogu Produktu Jak zjeść słonia? Najlepiej po kawałku. Tak też jest z Backlogiem Produktu. Jak to zrobić? Jak podzielić Backlog Produktu na mniejsze elementy? Jakie metody warto wykorzystać w tym procesie? Spis treści Metody dzielenia Backlogu ProduktuNasze wskazówki dotyczące dzielenia elementów Backlogu ProduktuFAQ: Dzielenie elementów Backlogu Produktu📄Transkrypcja podcastu „Dzielenie elementów Backlogu Produktu” W tym artykule właśnie opowiadamy o tym, jak dzielić elementy Backlogu na mniejsze kawałki. Jest on rozwinięciem odcinka 76, do którego przesłuchania Cię zachęcamy. Rozmawialiśmy w nim trochę szerzej o dzieleniu pracy małe kawałki pracę, jaką mamy do wykonania. Tu skupiamy się konkretnie na jednym Backlogu produktów, ale informacje te możesz wykorzystać też do dzielenia innych kawałków produktu (np. jeśli korzystasz z Kanbana czy innej metodyki), które masz do wykonania, np. User Stories czy różne feautre’y. Na wstępie chcemy Cię uprzedzić, że nie będziemy tu poruszać kwestii dzielenia dużego produktu na mniejsze obszary, za które mogą odpowiadać różne zespoły. Takie dzielenie jest zazwyczaj potrzebne przy okazji transformacji czy reorganizacji zespołów. Znajdziesz tu natomiast wyselekcjonowane najważniejsze metody dzielenia, kilka refleksji na temat dzielenia produktu oraz kilka porad liderów i managerów. Metody te omówimy dokładnie i podamy też ich przykłady, bazując na podstawie naszego doświadczenia jako użytkownicy, czy członkowie zespołów, czy doradcy tychże zespołów.  Oczywiście nie wymienimy wszystkich znanych nam metod dzielenia. Jest ich naprawdę dużo, a niektóre są dosyć specyficzne i może nie zawsze aż tak uniwersalne. Metody dzielenia Backlogu Produktu 1. Metoda poszukiwania prostego rozwiązania Jest to bardzo generyczna metoda, polegająca na zastanowieniu się, czy konkretne rozwiązanie, feature lub kawałek produktu, który chcemy zrealizować, możemy dostarczyć na początku w dosyć uproszczonej wersji. Chodzi o to, aby dać dostęp do produktu, bez złożonych opcji, które zwykle konsumują bardzo dużo czasu, a niekoniecznie są niezbędne, żeby oddać kawałek produktu naszym użytkownikom. Przykładem jest tu aplikacja Brand24 służąca do monitoringu internetu. Jacek korzystał z niej przez interfejs webowy, a pewnego dnia ściągnął aplikację mobilną, która nie posiadała wszystkich funkcjonalności, co wersja webowa. Mimo pierwszego niezadowolenia zrozumiał, że jednak woli mieć dostęp do tak uproszczonego produktu w wersji na telefon niż nie mieć tej możliwości wcale. Proste rozwiązania nie tylko pozwalają nam szybciej dostarczyć pierwszą wersję produktu do klienta, ale i często są to rozwiązania po prostu przyjazne w użyciu. Dobrym przykładem jest tu świat e-commerce, gdzie wiele lat temu przy rejestracji wymagano od nas podania wielu informacji, a formularz składał się z wielu pól, które nie zawsze wiadomo było jak wypełnić (np. format numeru telefonu). Teraz jest zupełnie inaczej, projektując formularze i inne elementy interfejsu użytkownika, zadajemy sobie pytanie “jaki minimalny zestaw informacji potrzebujemy na etapie rejestracji lub w pierwszej iteracji?”. Podejście opiera się na stworzeniu bardzo prostej wersji, którą w przyszłości możemy rozbudowywać, jeśli zajdzie taka potrzeba.  2. Metoda przez uproszczoną wersję interfejsu To specyficzna wersja metody poszukiwania prostych rozwiązań. Wykorzystywana jest ona w sytuacji, gdy mamy do czynienia z rozbudowanymi i wysublimowanymi wersjami interfejsów w produkcie docelowym, natomiast mamy mało czasu i chcemy szybko wypuścić jakieś rozwiązanie. Zwłaszcza gdy testujemy jakieś hipotezy. Możemy wówczas zrobić prostszą wersję tego interfejsu.  Przykładowo, kiedyś Kuba wspierał rozwój pewnego produktu z wieloma rozbudowanymi dashboardami. W pierwszych Sprintach, zamiast generować mnóstwo wykresów, tabelek i jakichś fajnych opcji, które docelowo miały się w tym produkcie znaleźć, zespół ograniczył się do wyświetlania tych samych informacji czystym tekstem na nieoszlifowanym interfejsie. O wiele ważniejsze było to, że tam są te informacje, a nie to czy są pokazane w ładnej tabelce, na wykresie czy kołowym diagramie.  Mamy wrażenie, że ta metoda jest bardzo rzadko wykorzystywana. Zwykle jest tak, że pewien kawałek produktu (np. strona logowania) jest definiowany wizualnie przez zespół UX/UI i dostarcza on zespołowi developerów gotową makietę, która jest piękna i przyjazna u

Rozmowa z Radkiem Orszewskim z podcastu Kanban przy kawie na temat stanu zwinności i trendach na 2022. Poruszyliśmy tematy pracy zwinnej zdalnej i hybrydowo, roli Scrum Masterów oraz kompetencji, jakie potrzebne są do takiej pracy. Porządny Agile · #080 – Quo vadis, Agile? 2022 Jaki jest stan zwinności i jakie trendy czekają nas w 2022 roku w świecie Agile? Jak praca zdalna i hybrydowa wpływa na Agile, jaka jest teraz rola Scrum Masterów i jakie kompetencje są potrzebne do takiej pracy.  Tematy te poruszyliśmy w rozmowie z Radkiem Orszewskim z podcastu Kanban przy kawie. Zapraszamy Cię do jej przeczytania i podzielenia się też Twoimi obserwacjami. Radek: Zacznę od przedstawienia gości naszej rozmowy, ale w taki trochę nietypowy sposób. Zaproszę Was do opisania tego, co robicie, na czym polega właściwie Wasza praca? Kuba, gdyby ktoś miał Cię zapytać, to jak Ty określasz swoją pracę? Kim jesteś zawodowo? Kuba: To zależy komu, to tłumaczę. Jeśli  cioci na imieninach czy sąsiadowi na grillu, to zaczynam od pracy zespołowej. Przedstawiam taką scenkę, mówiąc o tym, że firmy zajmują się rozwojem, np. aplikacji. Pracują całymi zespołami, a ja pomagam tym zespołom pracować lepiej, wydajniej i efektywniej. Natomiast, gdy przedstawiam się przed szkoleniem lub w kontekście wewnątrz firmowym to mówię, że pomagam firmom, które przechodzą zmianę. To już jest bardziej nakierowane na Agile, które pomagam wykorzystać i zrozumieć. Radek: Nie użyłeś żadnych rzeczowników czy nazwy stanowiska. Jacku, a jak Ty się przedstawiasz? Jacek: Ostatnio z żoną pytaliśmy syna, co robimy i stwierdził on, że mówię ludziom, jak mają pracować. To taka fajna praca, bo ja nie pracuję, tylko mówię innym, jak mają to robić. Oczywiście to trochę żartobliwie powiedziane, natomiast jak rozmawiam z osobami spoza branży, to mówię, że pomagam lepiej zorganizować pracę. To z kolei zwykle uruchamia jakieś dodatkowe pytania, a jeśli rozmówca jest zainteresowany, to wchodzimy w temat głębiej. Kuba: Jeśli miałbym nazwać jakoś swoje stanowisko, to użyłbym Agile Coach. Moim zdaniem jednak nie jest to najlepsze ujęcie tego stanowiska i bardzo rzadko go używam. Najczęściej pracuję z ludźmi, którzy nie do końca rozumieją, czym jest Agile, z kolei słowo “coach” bardzo negatywnie im się kojarzy. Zresztą Agile Coach dla każdego może znaczyć coś innego. Dlatego wolę mówić, że pomagam w pracy. Radek: Dobrze, to przejdźmy teraz do tematu odcinka, czyli zastanówmy się, dokąd zmierza zwinność w 2022. Fajnie się składa, że nie powiedzieliście konkretnych nazw stanowisk. I to, co dodałeś Kuba, że właściwie samo pojęcie jak Agile Coach, może znaczyć bardzo wiele rzeczy. Czasami już wręcz – nie bójmy się słowa – negatywnie pojmowanych.  Ja sam pracuję z organizacjami, w których widzę coraz to nowsze tytuły. Mamy Delivery lead’ów, Agile Delivery Managerów, a ostatnio spotkałem się z “Expert in ways of working”, czyli też pewna forma organizacji pracy.  Mamy też zmianę związaną ze Scrum Masterem, która pojawiła się dwa lata temu w Scrum Guide i która mówi o tym, że Scrum Master to już nie jest rola, a raczej odpowiedzialność. Czy to oznacza, że odchodzimy od pełnoetatowych Scrum Masterów?  Jak Wy to widzicie? Czy też ludzie, z którymi Wy pracujecie, mają takie spektrum różnych tytułów i czy to na coś wpływa? Jacek: Pewnie nikogo nie zaskoczę moją odpowiedzią, że tytuł ma tak naprawdę małe znaczenie. Widziałem developerów, którzy robili lepszą robotę niż pełnoetatowy Scrum Master i widziałem Project Managerów, którzy byli lepszymi Product Ownerami, niż osoby, które były dedykowane do produktu.  Nazwy pewnie będą się zmieniać, ale moim zdaniem są one wtórne. Bardziej chodzi o to, co robimy i jak to robimy. Znaczenie mają przywództwo, odwaga, asertywność. Kuba: Ja się trochę boję tego zjawiska, że te wymyślane nazwy stanowisk, w niektórych organizacjach, są pewnym rodzajem polemiki ze standardami czy mainstreamem. Chcą czegoś szerszego niż Scrum. Gdy czasem wchodzę w szczegóły w rozmowach tego typu, okazuje się, że firma wymyśla np. Agile Delivery Manager’a na funkcje lidera zwinności w swojej organizacji i ma na myśli naprawianie Agile’a, a nie jego usprawnianie. To naprawianie to wg. nich poprawiona samoorganizacja, gdzie jednak jest szef, który ma za wszystko odpowiadać.  Ja bym chciał, żeby w jak największej liczbie firm te wymyślne nazwy, były sygnałem o pewnej dalszej ewolucji. Natomiast boję się, że w większości organizacji niestety jest odwrotnie. Mam poczucie, że to jest taka próba polemiki z jakoś tam sprawdzającymi się modelami i próba dodania, na przykład mocniejszego liderstwa, czy mocniejszego zarządzania przez liderów, zamiast samoorganizacji. Ponadto, niestety często widzę łączoną rolę – trochę Product Owner, trochę Scrum Master, trochę szef, trochę kierownik projektu. I w ten sposób powstają bardziej pojemne nazwy stanowisk. Radek: Mam jeszcze jedno pytanie w tym obszarze. Znam kilka organizacji, w których osoby zajmujące

Poznaj technikę Magic Estimation. Możesz ją wykorzystać, gdy zaczynasz projekt lub nową inicjatywę w istniejącym zespole. Dajemy Ci gotową instrukcję użycia tej techniki i podpowiadamy, kiedy ją najlepiej zastosować. Wyjaśniamy, czym różni się od innych popularnych technik uzyskania estymat. Nie zabraknie też kilku istotnych wskazówek logistycznych. Porządny Agile · #079 – Magic estimation W tym artykule znajdziesz następujące treści: Spis treści Magic Estimation – na czym polega ta technika?Magic Estimation a inne techniki estymacji Jak przygotować się do sesji „magicznej estymacji”?FAQ: Magic Estimation📄Transkrypcja odcinka podcastu „Magic Estimation” Magic Estimation – na czym polega ta technika? Magiczna Estymacja czy też Magiczne Szacowanie to technika bardzo wstępnego estymowania zakresu pracy, który jest do wykonania w ramach rozpatrywanego dłuższego horyzontu czasowego (większe wdrożenie, projekt, kwartał albo dłuższy okres). Możemy ją wykorzystać zarówno w odniesieniu do nowej (większej) funkcji produktu, jak i do całego projektu czy ustalenia wersji MVP. Zasady „magicznej estymacji” Są 4 główne zasady związane z Magic Estimation: Wszystkie estymaty są błędne. Porównujemy elementy między sobą – co jest równe, mniejsze lub większe. Ta sesja nie zastępuje typowych Refinementów przed Sprintem. Dążymy do szybkiej, wstępnej oceny wielkości całego zakresu. Przebieg sesji Magic Estimation Sama sesja Magic Estimation przebiega według dosyć ściśle przestrzeganych reguł. Możemy ją podzielić na cztery konkretne rundy: I runda – każdy uczestnik rozkłada swoją porcję elementów w ciszy Cały zespół otrzymuje Backlog lub listę elementów zakresu pracy, która jest do oceny. Cały Backlog Produktu jest umieszczony na osobnych kartkach, a każda osoba dostaje do „ręki” (fizycznie lub wirtualnie) jakąś porcję tych kartek (czyli tylko ułamkową część całości). Następnie w absolutnej ciszy, bez żadnej komunikacji, każdy układa swoje kartki na przygotowanej wcześniej osi. Jedna strona osi oznacza najmniejsze zadania, drugi jej skraj przeznaczony jest na największe. Oś ta może być umieszczona na stole, na podłodze, na ścianie (w przypadku spotkania stacjonarnego). Jeśli spotkanie jest wirtaulne, do dyspozycji zespołu potrzebna jest odpowiednio duża tablica wirtualna (np. Miro, Mural). Każdy indywidualnie ocenia swoją porcję elementów Backlogu, rozkładając je według swojego uznania na osi, odpowiednio małe, średnie lub duże elementy.  Przeznaczone jest na to ok. 10 minut. II runda – uczestnicy przeglądają oceny wielkości pozostałych Każdy z członków zespołu przegląda kartki innych i ocenia ich rozmieszczenie na osi. Jeśli ktoś nie zgadza się z oceną wielkości, to bez konsultacji z innymi przesuwa kartkę na odpowiednie według niego miejsce. Na przesuwanej kartce umieszcza się kropkę. Dużo kropek oznacza, że jest to element do dyskusji, ponieważ różne osoby różnie tę kartkę oceniły.  Ta runda też trwa około 10 minut. III runda – wspólne przejście przez wyłonione grupy wielkości elementów Wszyscy uczestnicy spotkania przechodzą teraz przez wszystkie grupy kartek (małe, średnie i duże) i wspólnie określają czy faktycznie są umieszczone w dobrej grupie. Jeśli w zespole stosowane są Story Pointy, to jest to dobry moment, by je przyznać. W tej rundzie możliwe jest już dyskutowanie. Mimo wszystko nadal warto takie rozmowy moderować, by spotkanie nie przerodziło się w klasyczną dłuższą sesję Refinementu Backlogu Produktu. IV runda – rozstrzygane są wspólnie najbardziej sporne elementy Na końcu rozstrzygane są kwestie związane ze spornymi kartkami, czyli tymi, które mają najwięcej kropek. Ważne, by moderator spotkania zachęcał Zespół, żeby decyzję podejmować szybko, bez długiej dyskusji, bo w tym ćwiczeniu wycena nie musi być bardzo precyzyjna. Kiedy stosować Magic Estimation? Nie jest to uniwersalna technika wyceny i ma swoje zastosowanie w konkretnych kontekstach. Jest kilka momentów w czasie pracy zespołu lub życia produktu, kiedy warto wykorzystać Magic Estimation. Rekomendujemy stosowanie „magicznego szacowania” gdy: startujesz nowy projekt lub inicjatywę produktową albo będziesz pracować nad nowym wycinkiem produktu i chcesz uzyskać tylko bardzo wstępne szacunki wielkości, potrzebujesz poznać datę, bo np. interesariusze chcą wiedzieć, kiedy można się spodziewać kolejnego wdrożenia,  musisz zsynchronizować pracę kilku zespołów pracujących w trybie zwinnym, np. zespół marketingu przygotowuje kampanię telewizyjną i zespół obsługi klienta chce wiedzieć, kiedy może mieć więcej pracy po uruchomieniu reklamy, należy zrewidować zakres prac lub datę wdrożenia, bo np. pojawiły się przesłanki mówiące, że pierwotna data jest zagrożona, działasz w firmie według cyklicznie planowanej roadmapy, a Magic Estimation pozwoli Ci ocenić wielkość danej inicjatywy, czy nawet kilku inicjatyw, które są równolegle rozpatrywane. D

Podczas planowania bardzo często zauważamy, że zespoły są zespołami tylko z nazwy. Każdy robi to co ma przydzielone, nie angażuje się i nie wychodzi poza szereg. Mamy kilka hipotez na to, dlaczego zespoły nie planują. Chcemy dać Ci też inspiracje do tego, żeby planować zespołowo. To, co odkryjesz w zespole podczas planowania, może okazać się największą wartością z tego procesu (a nie sam plan, który się szybko dezaktualizuje). Porządny Agile · #077 – Dlaczego zespoły nie planują zespołowo? Spis treści Dlaczego zespoły nie planują zespołowo?Jak wdrożyć planowanie zespołowe w organizacji?FAQ: Dlaczego zespoły nie planują zespołowo?📄Transkrypcja podcastu „Dlaczego zespoły nie planują zespołowo?” Praca zespołowa dotyczy nie tylko wykonywania zadań, ale także etapu planowania. Dlaczego jednak ten drugi element jest często pomijany? Jak zacząć planować działania wspólnie, zamiast robić plany indywidualne? Podczas pracy z zespołami często widzimy, że mimo wdrażania praktyk zwinnych to gdy przychodzi do czynności planowania iteracji, sprintu czy wdrażania jakiegoś projektu to tak naprawdę brak tam planowania zespołowego. Jest to dużym błędem, bo to, co odkryjemy w zespole podczas planowania, może okazać się największą wartością z tego procesu. Sam plan ma mniejszą wartość, gdyż szybko się dezaktualizuje.   W tym artykule odpowiemy sobie na pytanie, dlaczego zespoły nie planują zespołowo i podpowiemy Ci jak zmienić ten stan rzeczy w Twoim zespole.  Nim jednak przejdziemy do przyczyn i rozwiązań przytoczymy Ci przykłady planowania w zespole, które ma niewiele wspólnego z planowaniem zespołowym. Zwykle jest tak, że zespół omawia konkretny zakres (zadań, wymagań, ficzerów), który zostanie wykonany. I na tym całe planowanie się kończy. Czasem zachodzi jeszcze indywidualny przydział zadań do członków zespołu. Nie jest to jednak planowanie zespołowe, nie powstaje również żaden faktyczny plan. W konsekwencji każdy martwi się o swój kawałek projektu, nie ma tu współpracy, a członkowie zespołu pracują obok siebie. Jednocześnie bardzo często okazuje się, że to, co w strukturze organizacji określane jest zespołem to tylko taki formalny kontener, składający się z jednostek. Oczywiście, łatwo nam powiedzieć, że coś nie działa, wskazać co dokładnie, a następnie wyliczyć listę praktyk, które mogą zapobiec lub usunąć jakiś problem. Dlatego najpierw warto poznać przyczyny takiego stanu rzeczy.  Dlaczego zespoły nie planują zespołowo? Bazując na naszych obserwacjach zebraliśmy 8 przyczyn problemów związanych z planowaniem zespołowym: Przyzwyczajenie do takiego trybu pracy. Możliwe, że członkowie zespołu nigdy w swojej karierze zawodowej nie mieli okazji poznania perspektywy prawdziwej pracy zespołowej i jest to dla nich całkowicie normalny stan.  Narzędzia elektroniczne, z których korzystają zespoły w pracy, zupełnie nie wspierają aktu planowania. Mamy tu na myśli takie narzędzia jak Trello czy Jira. Pozwalają one na wizualizację Backlogu Produktu czy listy zadań, jednak nie mają funkcjonalności wspierających planowanie zespołowe. Wyróżnianie poziomów specjalizacji i podział na wyraźnie stanowiska pracy. Jest to zrozumiałe i potrzebne m.in. jeśli chodzi o proces rekrutacji czy ustalanie ścieżek rozwoju pracowników. To jednak może utrudniać pracę w zespole, gdyż pracownicy mają świadomość odpowiedzialności, za swoją działkę, do której zostali zatrudnieni i z czego są też rozliczani.  Utylizacja stanowisk pracy, czyli oczekiwanie, że skoro zatrudniamy developera, to spędza on swój czas na programowaniu, natomiast zatrudniony tester zajmuje się tylko testowaniem. Powoduje to, że po prostu robimy to, co się od nas oczekuje, a takie wychodzenie poza nasz zakres, nie jest mile widziany. To z kolei stoi w sprzeczności ze współpracą zespołową. Maksymalizacja wyników pracy, czyli oczekiwanie, że wszyscy w zespole będą 100% czasu zajęci. Taka optyka, żebyśmy nie mieli żadnego przestoju i żebyśmy wciąż dążyli do tworzenia kolejnych ficzerów, bardzo utrudnia wspólną pracę. Przez to przykładowo tester nie jest w stanie przetestować wszystkiego, co do niego spływa od programistów i jest coraz bardziej przytłoczony, a to w rezultacie oddala zespół od realizacji kolejnych elementów projektu.  Szkolenia ze zwinności czy ze Scruma rzadko obejmują też rzeczy związane z planowaniem. Bardzo łatwo tu wpaść w pułapkę własnych doświadczeń. Gdy trener na szkoleniu mówi “Na planowaniu Sprintu zespół planuje”, to każdy z inaczej może to odczytać. Jeden zrozumie, że po prostu ktoś przypisuje mu zadania, inny, że wybieramy sobie sami zadania itd. Dlatego warto zadbać, aby na szkoleniu uczestnicy mogli faktycznie doświadczyć właściwego planowania i zobaczyć jak powinno wyglądać. Przekonanie, że planowanie nie jest zwinne. Często firmy przechodząc transformację ze świata bardziej projektowego, poukładanego, z mocną rolą kierownika projektu, mogą mieć poczucie, że należy porzucić planowanie, bo w Manifeście jest

Twój zespół nie wyrabia się z zadaniami? Terminy gonią, górka staje się coraz większa. Może warto podzielić pracę na mniejsze kawałki? Dowiesz się jakie korzyści przynosi taki podział. Zebraliśmy na to aż dziesięć argumentów. Dodatkowo mamy kilka wskazówek na to jak zacząć tak działać, czyli jak wprowadzić dzielenie pracy na mniejsze elementy w Twoim zespole. Porządny Agile · #076 – Dlaczego warto dzielić pracę na małe części? Jak zjeść słonia? Podobno najlepiej po kawałku. Warto w ten sam sposób podejść do pracy, jaką mamy do wykonania. Poruszymy temat Product Breakdown i korzyści z niego płynących.  Spis treści Jakie są korzyści z dzielenia pracy na małe części?Jak wdrożyć dzielenie pracy na małe części do zespołu?FAQ: Dlaczego warto dzielić pracę na małe części?📄Transkrypcja podcastu „Dlaczego warto dzielić pracę na małe części?” Jakie są korzyści z dzielenia pracy na małe części? 1. Łatwiej oddzielisz wartościowe elementy od mniej wartościowych Jest to istotne zwłaszcza z perspektywy biznesowej i wartości dodanej wytworzonej przez zespół. Wyobraź sobie, że masz do zrobienia duży formularz w systemie. Jeśli ten formularz potraktujesz jako pojedynczy element, to nie jesteś w stanie odróżnić mniej i bardziej wartościowych jego części. Jeśli natomiast formularz ten rozdzielisz na mniejsze elementy, które są częściej używane przez użytkowników i na te rzadziej używane, to możesz wydzielić w nim obszary krytyczne dla biznesu i obszary opcjonalne. Te drugie są mniej istotne i mogą być zrealizowane w późniejszym etapie. A może nawet całkowicie wyeliminowane, jeśli zajdzie taka potrzeba. 2. Podczas dzielenia odkryjesz niuanse pracy do wykonania W praktyce często w czasie dzielenia większego elementu, zaczyna się odkrywać, że na pewne pytania nie ma jeszcze odpowiedzi. Odpowiedzi te będą one potrzebne przed rozpoczęciem prac. Brakującą wiedzą mogą być jakieś szczegóły implementacji czy oczekiwań użytkowników. Mogą się tu kryć także jakieś nieznane uzasadnienia biznesowe lub ich brak. 3. Prościej oszacujesz pracę Z jednej strony, gdy rozpatrujesz mniejsze elementy produktu, to proces szacowania pracy i jej wyceny jest szybszy. Z drugiej strony, estymata, która uzyskasz, będzie trafniejsza i z mniejszą liczbą potencjalnych niedomówień czy  niespodzianek.  4. Łatwiej rozdzielisz pracę wewnątrz zespołu Mając więcej mniejszych kawałków, łatwiej jest rozdzielić pracę pomiędzy członków zespołów. Dzięki temu ciężar realizacji konkretnego zadania nie spoczywa na jednej osobie. Pozwoli to też skrócić Cycle Time. A w sytuacji, gdy trzeba będzie jeden z elementów produktu zrealizować wcześniej, będziesz mieć taką możliwość.  Mniejsze elementy pozwalają też oddzielić bardziej skomplikowane do wykonania części. Można je przekazać do bardziej doświadczonych pracowników. A te mniej skomplikowane części mogą być wykonane przez osoby z mniejszym stażem.  5. Wygodniej zarządzisz małą porcją pracy Gdy praca jest podzielona na mniejsze fragmenty, to łatwiej zrozumieć gdzie jesteś, jeśli chodzi o postęp pracy. Łatwiej zobaczyć te zadania, które są już faktycznie skończone, a także prościej jest przekazywać pracę między członkami zespołu.  Podczas codziennych spotkań szybciej też wychwycisz problemy niż w sytuacji, gdy ktoś ma tygodniowe zadanie na sobie. Pozostali członkowie zespołu mogą codziennie słyszeć tylko, że zadanie jest w trakcie. Gdy porcja pracy niewielka, to w sytuacji, gdy coś się przedłuża, można szybciej wychwycić takie odchylenie i odpowiednio zareagować. 6. Sprawniej opanujesz to, co jest do zrobienia W szczególności mamy tu na myśli pracę, która jest wymagająca intelektualnie. Dotyczy to wytwarzania między innymi nowych funkcjonalności. Gdy próbujesz zrobić duże zadanie na raz, ale w jego trakcie ktoś przerwie Tobie pracę, to później tracisz czas, aby powrócić do miejsca w procesie myślowym, w którym Ci przerwano. Jest to nie tylko czasochłonne, ale i stresujące.  7. Szybciej wykonasz Code Review Z doświadczenia wiemy, że zespoły, które realizują prace bardzo dużymi partiami, później mają też duży kłopot ze zrobieniem przeglądu kodu. Jest tego kodu po prostu za dużo. Gdy dołoży się do tego presję czasu, to może być ono robione na szybko i niestarannie. A to z kolei pociąga za sobą kolejne zagrożenia w postaci ukrytych w kodzie błędów. 8. Merge będzie mniej kłopotliwy W sytuacji kiedy chcesz połączyć wykonane zmiany z główną gałęzią kodu, prościej będzie tego dokonać, jeśli masz małe zmiany. Szansa na to, że w trakcie takiego merge’a pojawią się jakieś kłopotliwe konflikty, jest o wiele mniejsza, niż kiedy robisz dużą zmianę.  9. Znajdowanie przyczyny błędu będzie prostsze  Gdy do istniejącego produktu, oprócz nowych funkcji, dodasz niechcący błędy, łatwiej i szybciej będzie te błędy znaleźć i naprawić w mniejszych elementach. Łatwy będzie też proces testowania i ewentualnego re-testowania.  10. Otrzymasz wcześniejszy feedback   Obejmu

Velocity pokazuje, ile pracy wykonał zespół w określonym czasie. Miara ta jest bardzo popularna. Często jest pierwszym wyborem, choćby dlatego, że bywa gotową opcją w narzędziu do zarządzania produktami. Odcinek ten polecamy wszystkim zespołom i organizacjom, które starają się wykorzystać velocity. Podpowiadamy czego unikać i jak używać porządnie tej miary, a także co zrobić, żeby velocity miało sens. Porządny Agile · #075 – Jak sensownie wykorzystać velocity? W każdym procesie, także w procesie scrumowym, aby określić skuteczność wprowadzanych zmian i działań potrzebujemy miary, które pozwolą nam ocenić ich efekty. Popularną miarą w zespołach scrumowych jest Velocity, czyli sposób mierzenia prędkości.  Spis treści Czego unikać i jak poprawnie wykorzystywać velocity?Podsumowując, jak zatem sensownie wykorzystać velocity?FAQ: Jak sensownie wykorzystać velocity?📄Transkrypcja podcastu „Jak sensownie wykorzystać velocity?” Oczywiście, zgadzamy się z tym, że velocity nie musi być wykorzystywane przez każdy zespół. Ten artykuł dedykujemy jednak tym zespołom i organizacjom, które z tej miary chcą korzystać lub już korzystają. Chcemy Wam podpowiedzieć jak wykorzystywać velocity w poprawny sposób i czego unikać. Czego unikać i jak poprawnie wykorzystywać velocity? 1. Velocity może nie mieć sensu, jeśli będzie oparte o godzinowe albo dniowe wyceny. W takich przypadkach nie będzie ono faktyczną miarą prędkości pracy zespołu. Będzie ono bardziej bliskie jakiejś mierze pojemności, czy możliwości pracy zespołu, gdzie maksimum takiego Velocity będzie taką liczbą godzin lub dni ile zespół ma w ogóle do dyspozycji.  W takich przypadkach Velocity będzie pokazywało tylko czy zespół wyrabia to oczekiwane maksimum czy nie. Ponadto ograniczeniem zawsze będzie maksymalna możliwa pojemność zespołu (capacity), czyli ilość godzin i ilość dni, które dany zespół ma do dyspozycji na pracę. To będzie bardziej zabawa w raportowanie godzin. Takie velocity może wydawać się całkiem stabilne, bo zespół będzie mniej więcej zazwyczaj w okolicy tej samej ilości godzin. Jednak wynika to tylko z tego, że to nie jest prędkość zespołu, a po prostu ile godzin, ile dni do dyspozycji ten zespół miał w ramach danego Sprintu. Takie podejście nie ma sensu, bo bazujemy na niewłaściwej liczbie, która nie daje podstaw do wyciągania dalszych wniosków.  Żeby velocity jako miara prędkości zespołu w ogóle miało sens, trzeba bazować na faktycznych Story pointach. Muszą być one stabilne w czasie, czyli w różnych momentach pracy danego zespoły muszą oznaczać mniej więcej podobną wielkość czy złożoność pracy do wykonania. Dobrze też, aby miały stabilną skalę w długim horyzoncie czasowym.  Więcej o Story pointach i generalnie o estymowaniu mówiliśmy w odcinku #19 podcastu, do którego wysłuchania Cię zapraszamy.  W sytuacji, gdy nie mamy Story pointów, a elementy w Backlogu Produktu są podobnie małe, można oprzeć statystykę prędkości na liczbie elementów z Backlogu Produktu, które zostały ukończone. Mówimy tutaj bardziej o takiej przepustowości. Jednakże warunkiem koniecznym tu jest to, że elementy, które przechodzą nam przez proces, muszą być podobnej wielkości, a wszystkie elementy, które będą wyjątkowo większe, albo wyjątkowo mniejsze, będą ten odczyt zakłócać. Velocity bazujące na liczbie elementów jest po prostu sumą tych elementów w danym Sprincie, który porównujemy z poprzednimi Sprintami. Na odpowiednim poziomie ogólności, przy odpowiednio dużej puli tych elementów, będą do siebie wystarczająco podobne, żeby te trendy dawały nam jakiś obraz.  2. Velocity powinno reprezentować faktycznie ukończone kawałki produktu. W przypadku Scruma mamy tu na myśli przyrost produktu.  To co czym określamy jako “ukończone” jest kwestią umówienia się w zespole i ustalenia wspólnej definicji tego. Ważne jest tu, że nie interesuje nas prędkość czystego developmentu (np. bez testów czy integracji), a to, co zliczamy do velocity, powinno być gotowe do użycia przez osoby odpowiedzialne za biznes.  Niepokojącym zjawiskiem w tym obszarze jest naciąganie statystyk i naliczanie sobie Story pointów za zadania poboczne (np. warsztaty i szkolenia), które nie przynoszą wartości dodanej do produktu i tylko zaburzają statystykę. To trochę oszukiwanie samych siebie. Żeby velocity było dobrze stosowane warto mieć bardzo rzetelne Definition of Done, czyli definicję ukończenia. Oczywiście należy też tej definicji w sposób zdyscyplinowany przestrzegać w każdym Sprincie i co do każdego elementu. Trzeba zaakceptować fakt, że w niektórych Sprintach nie uda się ukończyć żadnego elementu i wówczas velocity wyniesie 0. To zresztą jasno pokaże, jaka jest zdolność zespołu do dostarczania przyrostu produktu, bez tłumaczenia się zajętością i zajmowania się wieloma zadaniami naraz (i nieukończeniem przez to żadnego zadania). 3. Velocity powinno być wykorzystywane do planowania kolejnych Sprintów. Spotykamy się z sytuacjami, gdzie zespół planuje więc

Chcemy Ci udowodnić, że Agile w organizacji ma wiele korzyści z biznesowego punktu widzenia. Jeśli jeszcze wahasz się, czy pracować zwinnie, to mamy siedem argumentów, które mogą Cię przekonać. Agile to nie tylko zwiększenie przychodów czy zysków ze sprzedaży, ale też możliwość obniżenia kosztów. Porządny Agile · #074 – Dlaczego agile jest opłacalny? Spis treści 7 powodów dlaczego Agile jest opłacalnyZarabiamy wcześniejDostarczamy wyższą wartość produktuTworzymy przewagi konkurencyjne produktuWcześnie weryfikujemy pomysły Przerywamy nietrafione inwestycjeEliminujemy marnotrawstwa w procesieWykorzystujemy potencjał zespołuFAQ: Dlaczego agile jest opłacalny?📄Transkrypcja podcastu „Dlaczego agile jest opłacalny?” Jakie korzyści niesie za sobą Agile? W jaki sposób wpływa na zyski firmy? Przyjrzyjmy się opłacalności podejścia zwinnego w firmie. Rozpoczynając wdrażanie Agile w organizacji lub zespole, warto określić sobie cel tego przedsięwzięcia. Jednym z nich jest aspekt finansowy, gdyż podejście zwinne pozwala nie tylko na zwiększenie przychodów ze sprzedaży produktu czy usługi, ale także na obniżenie już istniejących kosztów.  Oczywiście podejście zwinne wiąże się z nowymi kosztami, o czym rozmawialiśmy w odcinku 14 naszego podcastu, do którego wysłuchania Cię zapraszamy. Dziś skupimy się jednak na pozytywnym wpływie Agile na finanse firmy.  Poniżej przedstawiamy 7 argumentów za tym, że Agile jest opłacalny. Nim jednak do nich przejdziemy, musimy podkreślić, że w naszych argumentach opieramy się na scenariuszu bazowym, który porównujemy z podejściem planistycznym. Podejście planistyczne zakłada, że wszystkie inicjatywy, projekty, kroki rozwoju produktów w danej firmie realizowane są w sposób zaplanowany. Te mocno zdefiniowane ramy generują pewien plan, a plan ten jest w miarę szczelnie kontrolowany i przestrzegany. 7 powodów dlaczego Agile jest opłacalny Zarabiamy wcześniej Dzięki rozwijaniu produktu w sposób iteracyjno-przyrostowy, jesteśmy w stanie wcześniej dostarczyć ten produkt na rynek. To sprawia, że możemy zacząć zarabiać stosunkowo szybko. Co prawda nasz produkt może nie być jeszcze kompletną, ostateczną wersją produktu, ale już odpowiada na potrzeby odbiorców i jest w stanie przynosić zysk.  Wcześniejszy zysk wpływa też pozytywnie na cash flow danej inwestycji. Zaczyna się ona spłacać jeszcze przed zakończeniem etapu produkcji. Wcześniej też możemy osiągnąć Break even point, czyli moment, w którym zaczynamy na całej inwestycji zarabiać. To z kolei pozwala lokować pieniądze w kolejnych inwestycjach.  Dostarczamy wyższą wartość produktu Dzięki planowej pracy i przemyślanym decyzjom jesteśmy w stanie dostarczyć lepiej przygotowane produkty mające tym samym wyższą wartość.  Podejście iteracyjne i otwartość na informację zwrotną daje potencjał na lepszą efektywność, a nasze rozwiązania są lepiej dopracowane, bo reagujemy na zmiany.  Wyższa wartość produktu może przełożyć się na wyższe wyniki finansowe, gdyż produkt albo będzie lepiej zaspokajał potrzeby klientów, albo rozszerzy jego grupę docelową.  Tworzymy przewagi konkurencyjne produktu Dobrze realizowana praca zwinna podnosi prawdopodobieństwo, że zespół wypracuje coś unikalnego lub nieszablonowego. Przed firmą otwiera się okazja do strategicznej przewagi na rynku, a to może przyciągnąć więcej klientów. Ponadto sprzedawcy mają bardzo mocny argument w rozmowach lub przetargach. I znów, sprzedaż rośnie.  W przypadku produktu B2C, czyli skierowanego do klienta indywidualnego, również marketing zyskuje dodatkowe punkty wzmacniające komunikację i promocję.  Możliwość wypracowania przewagi konkurencyjnej, wzmacnia też otwartość na bycie blisko klienta i otwartość na jego feedback. Ankiety, badania, prezentacja pierwszych pomysłów czy rozwiązań daje szanse na otrzymanie wartościowych informacji zwrotnych, zwiększając szansę na stworzenie jeszcze lepszego produktu od tego, jaki zakładaliśmy stworzyć. Wcześnie weryfikujemy pomysły  Kolejną korzyścią finansową podejścia zwinnego jest szybsza rezygnacja z pomysłów czy inicjatyw, które nie będą przybliżać nas do celów biznesowych, a jedynie zwiększą koszty projektu. Pozwala na to weryfikacja pomysłów na wczesnym etapie ich realizacji, już nawet przed rozpoczęciem prac nad nimi.  Zatem oszczędność finansowa wynika z prostego powodu: nie podejmujemy pracy, która długoterminowo okaże się niewłaściwym kierunkiem.  Należy tu też dodać, że w organizacjach z mocno planistycznym podejściem do realizacji projektów, etap weryfikacji pomysłów czasami bywa bardzo dużym kosztem samym w sobie. Zdarza się tak, gdy weryfikacja ta obejmuje komitety zarządcze, przygotowanie biznes case’ów, głębokich analiz. W podejściu zwinnym, gdzie pomysły weryfikujemy dzięki wczesnym prototypom, kontaktom z klientem, wczesnych rozmów w zespole, etap ten przebiega sprawniej i oszczędniej.  Mamy tu także, pewną ciągłość myśli, czyli osoby, które wcześniej we

Czy rotacyjny Scrum Master to dobre rozwiązanie dla zespołu? Czasem nie, a czasem tak. Przedstawiamy Ci konfiguracje, kiedy takie rozwiązanie może być wykorzystane. Czy je rekomendujemy? Odpowiedź poznasz po przesłuchaniu tego odcinka. Rozmowa ma formę polemiki, czy takie rozwiązanie jest właściwe. Porządny Agile · #073 – Rotacyjny Scrum Master Scrum Master pełni bardzo ważną funkcję w zespołach zwinnych. Ma on wpływ nie tylko na sam zespół projektowy, wspiera także Product Ownera oraz całą organizację. Czy w związku z tym rotacyjny Scrum Master to dobry pomysł? A może zawsze rolę Scrum Mastera powinna pełnić tylko jedna osoba? Spis treści Czy rotacyjny Scrum Master to dobry pomysł?Jakie mamy obiekcje przed wdrożeniem funkcji rotacyjnego Scrum Mastera?FAQ: Rotacyjny Scrum Master📄Transkrypcja podcastu „Rotacyjny Scrum Master” Z pojęciem rotacyjnego Scrum Mastera mamy do czynienia wtedy, gdy rolę tę obejmuje nie jedna, a kilka osób. Sytuacja taka może występować w kilku przypadkach, np.: Zespół potrzebuje i chce mieć Scrum Mastera, jednak z jakichś względów nie jest to możliwe, np. firmy nie stać na zatrudnienie dedykowanej do tego osoby, a nikt w zespole nie ma odpowiednich kompetencji do tej roli. Wówczas jego rola rozdzielana jest na poszczególne osoby w zespole.  Zespół decyduje, że chce rozdzielić odpowiedzialność Scrum Mastera na kilka osób, bo przykładowo kilka osób ma doświadczenie lub kompetencje w tym obszarze. Poza zespołem zapada decyzja, że Scrum Master nie jest potrzebny, jednak zespół wykazuje potrzebę jego posiadania i podejmuje we własnym zakresie decyzję o rozdzieleniu tej roli pośród swoich członków. Zespół chce umożliwić kilku osobom pełnienie funkcji Scrum Mastera w ramach sprawdzenia kto będzie najlepszym kandydatem do pełnienia tej roli. Jest to od początku sytuacja przejściowa. Czy rotacyjny Scrum Master to dobry pomysł? Ponieważ pracowaliśmy i pracujemy z wieloma firmami, podzielimy się z Tobą naszymi obserwacjami dotyczącymi funkcjonowania przechodniego Scrum Mastera w zespole.  Z naszej dwójki, Jacek bardziej sceptycznie podchodzi do takiego rozwiązania, gdyż mimo że pracuje od 10 lat z zespołami zwinnymi, to nie widział udanej implementacji takiego modelu w praktyce. Wielokrotnie spotkał się z kolei z firmami, które po próbie wdrożenia tego modelu rezygnowały z wielu różnych przyczyn.  Generalnie rotacyjność Scrum Mastera w zespole może się sprawdzić jeśli jest to tymczasowa sytuacja. Na dłuższą metę może to zaburzyć funkcjonowanie zespołu, nawet takiego, który był zgrany i działał sprawnie.  Gdy każdy jest Scrum Masterem tylko na chwilę, to może nie zauważyć problemów, które powoli się nawarstwiają, a horyzont myślenia może mieć tylko do końca Sprintu. Nikt nie chce też zajmować się kłopotliwymi tematami.  Z drugiej strony, jeśli zespół ma zaradnego lidera, deweloperzy są zgrani, a kultura zarządzania firmą jest zdrowa, to zespół może świetnie sobie radzić bez oficjalnie powołanego Scrum Mastera – jego rolę nieformalnie pełni lider. Sami nie mamy już do czynienia z takimi sytuacjami, ale wierzymy, że jest to możliwe i zapewne lepiej to zadziała niż losowy członek zespołu będący Scrum Masterem od czasu do czasu w ramach modelu rotacyjnego. Jakie mamy obiekcje przed wdrożeniem funkcji rotacyjnego Scrum Mastera? Przede wszystkim zakres wiedzy, jaką musi przyswoić Scrum Master jest tak szeroki, że bardzo trudno jest to zrobić z doskoku, czy przy okazji. Osoba, która chce być dobrym Scrum Masterem musi zainwestować sporo czasu w zdobywanie wiedzy, m.in. z zakresu facylitacji, procesu grupowego, podstaw coachingu, praktyk zwinnych, itd. Jeśli jednocześnie chce się być dobrym developerem to tego czasu na rozwój zdecydowanie zabraknie. A przecież oprócz zdobywania wiedzy, Scrum Master dużo czasu poświęca także na planowanie warsztatów, rozmowy, współpracę z Product Ownerem czy rozwiązywanie problemów w zespole.  W przypadku rotacyjnego Scrum Mastera pojawia się też problem realizacji większych tematów rozciągniętych na kilka tygodni lub miesięcy. Tak jak już wspominaliśmy o tym powyżej, punktowy Scrum Master może być niewystarczającym ogniwem, ze względu na brak ciągłości działań. Będzie się on sprawdzał przy prostych kwestiach, te większe, które mogą mieć realne przełożenie na flow zespołu, nie będą podejmowane, bo brak tu myślenia o długofalowym budowaniu usprawnień czy nawyków w zespole.  Przestrzegamy też przed pomysłem przekładania modelu rotacyjnego Scrum Mastera na całą firmę. Mamy na myśli sytuację, w której duża, wielo zespołowa organizacja, mająca swoje problemy, mówi ustami menedżerów zarządzających zespołami wytwórczymi, że u nich stanowisko Scrum Mastera nie funkcjonuje, nie wierzą w Scrum Masterów, bo to jest przecież rola, która jest rotacyjna. Jest to szczególnie niebezpieczne w przypadku firm, które dopiero startują w Scrumie lub mają bardzo różnorodne wyzwania albo też zespoły znajdują się na różnych etapach zaa

Jak możesz wspierać samoorganizację w zespole? Skorzystaj z siedmiu sprawdzonych przez nas porad, które będą przydatne dla menedżera lub lidera zespołu. Rozmowa jest w szczególności dedykowana tym osobom, które na co dzień zarządzają zespołami zwinnymi. Samoorganizujący się zespół potrafi pracować bez kierowania nim przez osoby z zewnątrz, ale udowadniamy tezę, że manager nadal ma sporo zadań do zrobienia. Porządny Agile · #072 – Jak wesprzeć zespół w samoorganizacji? Zarządzasz zespołem i zastanawiasz się, jak możesz wspierać w nim samoorganizację? Bazując na naszym wieloletnim doświadczeniu w pracy z Zespołami Zwinnymi, podzielimy się z Tobą jak to zrobić. Poznaj 7 porad jak rozwijać samoorganizację w zespole. Spis treści Jak wesprzeć zespół w samoorganizacji?Pomóż zrozumieć czym jest samoorganizacja Zadbaj o to, żeby zespół znał celDawaj informacje do podejmowania decyzjiZapewniaj potrzebne kompetencjeZdefiniuj granice samoorganizacji Aktywnie wspieraj zespół Reaguj, gdy jest to konieczneFAQ: Jak wesprzeć zespół w samoorganizacji?📄Transkrypcja podcastu „Jak wesprzeć zespół w samoorganizacji?” Artykuł ten kierujemy przede wszystkim do menedżerów funkcjonalnych, a także liderów zespołów. Jeśli jesteś np. Scrum Masterem lub Agile Coachem to koniecznie przeczytaj tej wpis. Z kolei, jeśli jesteś członkiem Zespołu Zwinnego i temat Cię interesuje, to zachęcamy do podzielenia się naszymi poradami ze swoim szefem. Jak wesprzeć zespół w samoorganizacji? Pomóż zrozumieć czym jest samoorganizacja  Jak wspomnieliśmy powyżej, samoorganizujący się zespół, to jest taki zespół, który samodzielnie podejmuje decyzje co do tego, jak zostanie zrealizowana praca. Zwróć uwagę na to, że mówimy o tym, jak zrealizować pracę, a nie o tym, jak wymyślić sobie cokolwiek do zrobienia i jak to zrobić.  Warto upewnić się, że zarówno zespół, jak i menedżer, tak samo rozumieją, co ten termin oznacza. W tej kwestii zachęcamy Cię do przesłuchania odcinka o komunikowaniu zmiany w zespole.  Powiedz zespołowi o swoich oczekiwaniach, klarownie przedstaw swoją definicję, a także zasygnalizuj, jakie będą zasady funkcjonowania zoptymalizowanego sposobu pracy.  Zadbaj o to, żeby zespół znał cel Niezależnie od tego kto ustala cel do osiągnięcia, Ty jako menedżer lub lider musisz zapewnić zespołowi cel, do którego zmierza. Zespół ma wybrać drogę, ale ta droga ma prowadzić do jakiegoś konkretnego sensownego miejsca. Co ważne, cel ten musi być jasny i zrozumiały dla każdego członka. Dawaj informacje do podejmowania decyzji Aby zespół mógł podejmować sensowne decyzje, musi mieć informacje, na których może bazować. Mówimy tu zarówno o informacjach technicznych, jak i biznesowych. To mogą być dane rynkowe na temat obszaru, dla którego nasz produkt przygotowujemy. To mogą być informacje z wewnątrz organizacji, które determinują w jakimś stopniu, jak ten produkt powinien się zachowywać. Co zespół może, a czego nie. Z kolei, od strony technicznej zespół znać wskaźniki do monitorowania, wizję przyszłej architektury, czy preferowaną technologię.   Jeśli zespół pójdzie w inną stronę, niż oczekujesz lub podejmie niezbyt mądre decyzje, to zastanów się najpierw czy miał on ten sam zestaw informacji, które Ty masz oceniając te decyzje i dając feedback.  Zapewniaj potrzebne kompetencje Jeśli chcemy, aby zespół radził sobie całkowicie samodzielnie, a do tej pory jakieś elementy były wykonywane ze wsparciem osób z zewnątrz, to zapewnij w zespole wszystkie kompetencje niezbędne do podejmowania decyzji, jak i do wykonywania pracy.  Dotyczy to zarówno kompetencji technicznych, jak i biznesowych. Bardzo ważne są też kompetencje miękkie i organizacyjne, które do tej pory mogły nie być, aż tak istotne. Zdefiniuj granice samoorganizacji  Z naszych doświadczeń wiemy, że bardzo często samoorganizacja jest traktowana bardzo zerojedynkowo. Albo jej nie ma, albo jest. Jeśli jest, to pojawia się myśl, że teraz możemy wszystko zmieniać, kwestionować i modyfikować. Dlatego zawsze powinny być określone jakieś granice tej samoorganizacji dla zespołu.  W zależności od organizacji ta swoboda może być bardzo duża, albo odwrotnie – niewielka. Przykładowo w firmie wytwarzającej produkty cyfrowe zespół może nie mieć wpływu na zmianę technologii, jednak może decydować, jaki framework frontendowy wybrać. Z kolei w branży finansowej jest cała strefa regulacji, procedur, sposobów postępowania, na które zespół może nie mieć już wpływu. W innych firmach z kolei wysoki priorytet ma etyka działania, dbania o środowisko i dobro społeczeństwa.  Dlatego w ramach wspierania samoorganizacji należy przedstawić zestaw reguł, które mają być przestrzegane. Warto też podkreślić też te sfery, w których zespół może funkcjonować samodzielnie, gdzie ma elastyczność w działaniu i podejmowaniu decyzji.   Aktywnie wspieraj zespół  Jako menedżer unikaj postawy wycofania, którą czasem nazywamy “abdykacją mene

Kontynuujemy cykl odcinków na temat porządnego wykorzystania Scruma. Backlog Sprintu jest w naszej ocenie dosyć często pomijanym artefaktem scrumowym. W zespołach, do których dołączamy, widzimy, że jest traktowany po macoszemu. Nie jest dobrze wykorzystywany w praktyce. Po przesłuchaniu tego odcinka będziesz teraz wiedzieć, po czym poznać porządny Backlog Sprintu. Porządny Agile · #071 – Porządny Backlog Sprintu Czym jest Backlog Sprintu i dlaczego jest tak ważny? Jak przeprowadzić porządny Backlog Sprintu, aby spełniał swoje zadanie. Przeczytaj nasze wskazówki oparte na pracy z zespołami zwinnymi. Spis treści Po czym poznać porządny Backlog Sprintu?FAQ: Porządny Backlog Sprintu📄Transkrypcja podcastu „Porządny Backlog Sprintu” Backlog Sprintu to jest jeden z artefaktów scrumowych, który bywa dosyć często pomijany lub traktowany bez należytej uwagi. Przyczyną tego może być fakt, że jest to wewnętrzne narzędzie developerów i nie jest on istotny dla interesariuszy spoza zespołu. Backlog Sprintu składa się z trzech składowych: z Celu Sprintu z konkretnego zakresu Backlogu Produktu,  planu dostarczenia przyrostu.  Dopiero kiedy występują te trzy elementy, możemy mówić o tym, że mamy Backlog Sprintu. Po czym poznać porządny Backlog Sprintu? Przede wszystkim zacznijmy od tego, że w ogóle podstawą jest wykorzystywanie Backlog Sprintu, bo jak wspomnieliśmy wcześniej, nie jest to regułą. Bywa tak, że jest jakiś Backlog Produktu. Na planowaniu umawiamy się, co mniej więcej z tego Backlogu Produktu zostanie wybrane i zrealizowane. Nie powstaje  jednak ten fizyczny artefakt, czyli Backlog Sprintu, który byłby reprezentacją tego, co wybraliśmy ze Sprintu.  Taki Backlog Sprintu pokazywałby, jaki jest cel i jaki jest konkretny plan na to, żeby konkretny Sprint zrealizować. Może on mieć postać jakichś karteczek, czy flip-charta, a w wersji elektronicznej być przygotowany np. w jakimś narzędziu typu wirtualna tablica, jak np. Miro lub Mural.   Druga porada jest związana z samą definicją Backlogu Sprintu i jego 3 składowych, o których wcześniej wspomnieliśmy. Wszystkie te 3 składowe muszą być przedyskutowane, czy przepracowane przez deweloperów w trakcie planowania pracy na początku Sprintu.  Z naszego doświadczenia wiemy, że z tych 3 składowych (cel, zakres i plan) najczęściej pojawia się zakres, czyli to, co sobie wybieramy z Backlogu Produktu. Następnie pod kątem częstotliwości występuje Cel Sprintu, o którym nagraliśmy cały osobny odcinek – jest to odcinek nr 7 i zachęcamy Cię do jego wysłuchania.  Czasem ten cel jest niedoskonały, czasem to jest kilka celi – zwanych potocznie wielocelem, jednak co najważniejsze, pojawia się.  Natomiast najczęściej brakującym elementem jest ten konkretny plan pracy. Jest on jednak bardzo istotny, gdyż mówi on kto się, zajmie czym, kiedy, w jakiej kolejności i jakie są zależności wewnętrzne oraz zewnętrzne. Pozwala on też zobaczyć jak na ten plan, przekładają się nasze kompetencje, gdzie pojawiają się wąskie gardła. Plan zmniejsza ryzyko niepowodzenia, a z drugiej strony zwiększa szanse, na to, że Cel Sprintu zostanie osiągnięty.  Kolejną poradą, jaką chcemy Ci przekazać, jest uwzględnienie tego, że Backlog Sprintu jest planem, który może ulec zmianie. W praktyce oznacza to to, że to, co sobie zespół planuje w ramach planowania Sprintu, jest prawdziwe przez jeden, może dwa dni. I bardzo szybko okazuje się, że jakieś zadania okazują się trochę bardziej złożone, niż myśleliśmy. Potrzeba na nie więcej czasu. Trzeba dołożyć dodatkowe zadanie lub ktoś idzie niespodziewanie na L4. Należy być na to gotowym i podchodzić do planu jako elementu elastycznego, który jest dobrym punktem startowym, ale na pewno będzie się zmieniał.  Więcej o planowaniu sprintu posłuchasz w odcinku 13.   Ważne jest też, aby wizualizować Backlog Sprintu. Najprościej rzecz ujmując, jest to pokazanie całej pracy realizowanej w sprincie i poukładanie jej w sposób, który pomaga ją zrozumieć.  Mówiąc o całej pracy, mamy na myśli, żeby nie było jakiejś szarej strefy, którą można rozpatrywać na dwóch poziomach. Pierwszy przypadek jest wtedy, gdy członek zespołu wykonuje konkretną pracę, ale nie jest ona odzwierciedlona w Backlogu Sprintu. Można wówczas przyjąć, że ta osoba ma przestrzeń na inne zadania. Drugi przypadek jest wtedy, gdy Product Owner nie wie, że zespół, z którym pracuje, czy w którym pracuje, zajmuje się czymś, co nie było omówione podczas planowania Sprintu. Oba przypadki sprawiają, że zdolność produkcyjna zespołu na etapie planowania jest w pewien sposób zaburzona. To ma też później konsekwencje związane z usprawnianiem, gdyż członkowie zespołu mogą nie wiedzieć o danym elemencie pracy, który nie zostaje uwzględniony podczas szukania usprawnień w procesie. Pamiętajmy też, aby dobierać takie sposoby wizualizacji, żeby łatwo było zrozumieć każdemu członkowi Zespołu Scrumowego, jakie zadania są na konkretnym etapie i gdzi

Jasny i transparentny przekaz informacji jest bardzo ważny w każdej organizacji. Co z tego, że osoba decyzyjna w firmie ma pewną koncepcję, jeśli zostanie ona niepoprawnie przekazana pracownikom. Ktoś coś źle zrozumie, inny nie usłyszy i efekt będzie odmienny od założonego. Zmiana nie jest skuteczna, kiedy komunikacja jest niedoskonała. Poznaj nasze sprawdzone metody na to, jak dobrze komunikować planowane zmiany. Zainspiruj się i wybierz z nich coś dla siebie. Porządny Agile · #070 – Praktyki komunikowania zmiany Spis treści Przygotuj plan komunikacjiWyjaśnij cel zmianyDopasuj komunikat do odbiorcówRozmawiaj, nie komunikujKomunikuj się często i na różne sposobyPreferuj komunikację bezpośredniąZaangażuj w komunikację liderów opiniiSprawdzaj, co słyszy odbiorca FAQ: Praktyki komunikowania zmiany📄Transkrypcja podcastu „Praktyki komunikowania zmiany” Jak komunikować zmianę w organizacji? Do czego może prowadzić nieprawidłowe komunikowanie zmiany? Jakich błędów unikać podczas komunikowania zmiany? W tym artykule podzielimy się z Tobą praktykami komunikowania zmiany, z którymi spotkaliśmy się w naszej przeszłości. Doświadczyliśmy tego zarówno wewnątrz organizacji, jako osoby zmieniające firmę od środka, jak również z perspektywy doradcy z zewnątrz.  Praktyki te opiszemy, bazując na konkretnych sytuacjach, w jakich zostały wykorzystane. Porównaj je do swojej sytuacji i wybierz te, które w Twoim przypadku mogą się sprawdzić. Traktuj je jako inspirację i dostosuj do rzeczywistości organizacji czy zespołu, z którym pracujesz. Nim przejdziemy do konkretnych praktyk, warto wspomnieć, dlaczego niedostateczne zakomunikowanie zmiany stanowi problem. Po pierwsze, z powodu niedoskonałej komunikacji, zmiana nie będzie skuteczna, a oczekiwane korzyści mogą nie zostać osiągnięte. Po drugie, zespół nie będzie w pełni zaangażowany w zmianę, nie do końca może rozumieć jej sens i cel, a efekty będą widoczne z opóźnieniem i nie będą tak dobre, jak na początku zakładano. Te dwa powody są już wystarczająco mocne, aby zadbać o prawidłowe komunikowanie zmiany. Przygotuj plan komunikacji Plan komunikacji możesz stworzyć samodzielnie jako lider zmiany lub wraz z grupą wdrażającą zmianę. W ramach tego należy przemyśleć i ustalić: grupę docelową, czyli do kogo ta zmiana musi dotrzeć, do kogo ta zmiana musi być zakomunikowana, planowane kanały komunikacji, czyli jakie metody komunikacji zostaną użyte,  zarys harmonogramu komunikacji, czyli kiedy i jak często będą komunikowane elementy zmiany,  jakie rzeczy chcemy komunikować, jakie kwestie powinny być poruszone w komunikacji Pomimo że poruszamy się w tematyce Agile, to warto zaplanować te kilka kwestii. W ferworze pracy i natłoku bieżących zadań łatwo zapomnieć o istotnych aspektach, które chcieliśmy przekazać. Stąd też warto na start przygotować sobie taki plan. Jednak chcieliśmy podkreślić, że jego posiadanie nie wyklucza pewnej spontaniczności. Plan może się zmienić w zależności od rozwoju sytuacji, np. gdy widzimy, że nasza grupa odbiorców reaguje wcześniej, niż zakładaliśmy. Wyjaśnij cel zmiany Podaj przyczynę zmiany. Wytłumacz w komunikacji, dlaczego zmiana jest istotna, jaki problem rozwiązuje w organizacji, jakie korzyści przyniesie.  Przyczyną zmiany może być np. brak przejrzystości pracy, zmiany w prawie, zmiany w otoczeniu, firma się rozrasta.  Znając powód zmiany, łatwiej tę zmianę zrozumieć. Bez zrozumienia trudno wymagać zaangażowania w zmianę i uzyskania dobrych efektów. Dopasuj komunikat do odbiorców Mamy tu na myśli zarówno język komunikatu, jak i jego formę. Zastanów się, kto jest odbiorcą komunikatu, jaką drogą może on do niego dotrzeć? Czy konkretny kanał komunikacji jest dostępny do wszystkich odbiorców?  Przykładowo jeśli mamy firmę produkcyjną, a zmiana dotyczy całej organizacji, to komunikacja za pośrednictwem poczty e-mail może nie być najlepszym pomysłem. Część pracowników, która nie potrzebuje do pracy własnego e-maila, nie dowie się o zmianach, które ich też dotyczą. Podobnie może być także w przypadku sprzedawców, dla których priorytetem są e-maile od klientów. Do ogólnofirmowych wiadomości mogą dotrzeć z dużym opóźnieniem albo wcale, zwłaszcza jeśli ich treści będą bardzo długie. Dlatego tak ważne jest, aby przemyśleć sposób komunikacji. Unikaj też tzw. korpomowy, buzzwordów, okrągłych słów, które ładnie wkomponowują się w całość komunikatu. Mogą one zostać niezrozumiane przez pracowników, przez co nasze wiadomości nie spełnią swojego zadania. Uważaj też na modny ostatnio storytelling, używanie dużej liczby metafor i analogii. Przykładowo prezes organizacji opowiada jakąś historię, która nie rezonuje z częścią pracowników, bo mają oni np. inne priorytety czy wartości w życiu. Prezes może i chciał dobrze, poświęcił czas na przygotowanie historii, ale ona bardziej usypia niż tłumaczy cokolwiek.  Prawdopodobnie w większości firm, z wyjątkiem tych takich naprawdę mocno homogenicznych, niedużych organi

Uczucie stresu w pracy z pewnością jest Ci znane. Nie znamy nikogo, kto choć raz nie był w stresującej sytuacji. Zatem skoro wszyscy się stresują, to czy jest to na porządku dziennym? My też często miewamy takie sytuacje, jak na przykład start współpracy z nowym klientem czy prelekcje przed dużą publicznością. Chcemy Ci przekazać nasze sposoby na radzenie sobie ze stresem. Nie zabraknie osobistych historii. Porządny Agile · #069 – Jak radzimy sobie ze stresem? Stres w pracy od czasu do czasu odczuwa większość z nas. Jego siła i częstotliwość zależą od wielu czynników. Różnie też reagujemy na sytuacje stresowe. Niemniej jednak warto mieć kilka sposobów na radzenie sobie ze stresem. Dlatego w tym artykule podzielimy się z Tobą naszymi sposobami. Spis treści Jakie sytuacje mogą wywoływać stres w zespołach zwinnych?Jak radzimy sobie ze stresem – 11 sposobów, które u nas działająFAQ: Jak radzimy sobie ze stresem?📄Transkrypcja podcastu „Jak radzimy sobie ze stresem?” Sposoby radzenia sobie ze stresem, które tu opisujemy, potraktuj jako inspirację. Być może w Twoim przypadku się nie sprawdzą. Mamy natomiast nadzieję, że pomogą Ci wypracować nowe lub udoskonalić obecne techniki zmniejszania wpływu stresu na Twój organizm.  Dlaczego postanowiliśmy poruszyć ten temat? Dlatego, że pracując w środowisku zwinnym, jesteśmy narażenie na wiele potencjalnych sytuacji stresowych. Jakie sytuacje mogą wywoływać stres w zespołach zwinnych? duża dynamika zmian lub wręcz odwrotnie: bierność i brak zmian, których oczekujemy,  praca z ludźmi i np. sytuacje konfliktowe, publiczne zajmowanie głosu, np. wystąpienia, prowadzenie szkoleń, realizowanie warsztatów,  praca z oporem. Stres oczywiście może mieć pozytywne skutki, ale niestety bardzo często jest przyczyną zmęczenia oraz obniżonej efektywności i jakości pracy. Długo trwający stres może też całkowicie zniechęcić do pracy i pociągać za sobą dalsze konsekwencje. Przykładem tego typu sytuacji jest np. Scrum Master czy Agile Coach będący pod ciężkim stresem. Jest zmęczony i zirytowany. To powoduje, że podczas rozmowy z ważną osobą w toczącej się transformacji (np. dyrektorem), błędnie odczytuje jego intencje. To z kolei może spowodować, że nie odpowiada na pytanie lub zaognia jakąś sytuację. Być może tworzy zupełnie nowy kryzys, gdyż stracił kontrolę i nie panował nad swoim działaniem.  Jak radzimy sobie ze stresem – 11 sposobów, które u nas działają 1. Naucz się rozpoznawać, że jesteś w stresie. Jakie symptomy wskazują na to, że się stresujesz? Może odczuwasz fizyczny niepokój, czujesz się słabszy i miękną Ci nogi? Czy masz trudności z zasypianiem przez gonitwę myśli w głowie? A może sen jest niespokojny i budzisz się kilka razy przed budzikiem, co normalnie nie ma miejsca? Także w ciągu dnia czujesz się przytłoczony, łatwo się denerwujesz? Masz krótszy oddech i trudno Ci wypowiedzieć dłuższe zdania? To wszystko może być objawem stresu, dlatego obserwuj siebie w potencjalnie stresujących sytuacjach. U każdego z nas te objawy mogą być inne, a ich rozpoznanie pozwoli Ci wprowadzić kolejne techniki łagodzenia stresu i skutków, jakie za sobą pociąga. 2. Poukładaj sobie motywację i cel swojego działania. Bądź świadom, po co robisz, to co robisz. Odpowiedz sobie na pytania: dlaczego lubisz to co robisz? Jak Twoja przeszłość udowadnia Ci, że pewne rzeczy po prostu takie są? Przykładowo pracując z zespołami zwinnymi czujesz, że wpływasz na to, że ludziom pracuje się lepiej. Więc jeśli gdzieś spotykasz opór, jakieś zniechęcenie i wątpliwości, czy złośliwości w swoim kierunku, to masz świadomość, że robisz to w jakimś większym celu, że pomagasz innym ludziom. Dodatkową motywacją jest też oczywiście kwestia finansów i zapewnianie rodzinie godnego życia.  Motywacją może być też poczucie rozwoju i ciągłej nauki nowych rzeczy. Wchodząc w nową branżę lub robiąc znane Ci rzeczy, ale w innym języku, czujesz, że zdobywasz nowe doświadczenia i liczysz się z tym, że stres jest tu nieodłącznym elementem.  3. Przygotuj się do wykonywanego zadania. Przygotuj się do tego, co będziesz wykonywać i co będzie Cię stresować. Jeśli masz wystąpić na konferencji to, przećwicz sobie swoje wystąpienie w domu, mówiąc do kogoś z domowników lub do wirtualnej publiczności. Zrób to kilka, a nawet kilkanaście razy. Dzięki temu, wychodząc już na właściwą scenę, wiesz, że robiłeś to wielokrotnie i zrobisz to po prostu jeszcze raz.  Podobnie można przygotować się do Retrospektywy. Przemyśl potencjalne scenariusze spotkania, zastanów się, czy przewidziałeś wszystkie możliwości, jak zareagujesz, jeśli pomysłów będzie za dużo albo nie będzie ich wcale?  Bardzo pomaga odpowiedź na pytanie: co najgorszego może się wydarzyć? Będziesz mógł odpowiednio zareagować, bez konieczności podejmowania szybkich, nieprzemyślanych decyzji. 4. Korzystaj z checklist. Aby dodatkowo nie stresować się myślami o tym, czy o wszystkim pamiętamy, czy wszystko zrobiliśmy, warto spis

Twój zespół startuje z nową inicjatywą i zastanawiasz się co wybrać. Jak ma pracować? Scrum nie zawsze jest tutaj pasującym wyborem. Jest jednym z najpopularniejszych frameworków i dlatego zwykle jest brany pod uwagę jako pierwszy. Rzucamy światło na to kiedy naszym zdaniem Scrum nie powinien być stosowany. Porządny Agile · #068 – Kiedy Scrum nie jest odpowiedzią? Najbardziej popularnym frameworkiem pracy w zespołach zwinnych jest Scrum. Jednak czy zawsze jest on dobrym wyborem? Kiedy Scrum nie powinien być stosowany i jakie czynniki na to wpływają? Spis treści Kiedy Scrum nie powinien być stosowany?Brak wspólnego celuBrak złożonego problemu do rozwiązaniaBrak kandydata na Product OwneraBrak samodzielności i autonomiczności zespołuNatura pracy nie wymaga współdziałania w zespoleCzłonkowie zespołu nie mają przestrzeni czasowej na pracę w danym zespoleZespół musi zrobić idealną wersję produktu za pierwszym razemPlanowanie przedmiotu pracy nie jest możliwe Firma nie jest gotowa zmieniać się w tych sferach, gdzie jest to niezbędne FAQ: Kiedy Scrum nie jest odpowiedzią?📄Transkrypcja podcastu „Kiedy Scrum nie jest odpowiedzią?” Podejmując nową inicjatywę lub tworząc nowy zespół, warto się zastanowić jaki framework pracy zwinnej sprawdzi się najlepiej w tej konkretnej sytuacji, w tym zespole lub w tym projekcie. Mimo że Scrum jest najpowszechniejszą metodyką zwinną to są pewne kryteria czy też czynniki, kiedy to warto z niego zrezygnować.  Kiedy Scrum nie powinien być stosowany? Brak wspólnego celu Pierwszym kryterium powodującym, że Scrum się nie sprawdzi, to sytuacja, gdy zespół nie ma wspólnego celu. Jest to bardzo istotny czynnik wpływający na pracę zespołu, ponieważ cel jest fundamentem pracy zespołu, wskazuje kierunek działania i sens realizacji projektu. Bez jednego celu lub przy kilku różnych celach, nawet przy wdrożeniu pewnych elementów Scruma, to jedna z wartości tego frameworku, czyli skupienie, będzie pogwałcona. W takim przypadku zespół będzie działał bez poczucia celowości, a każdy z członków będzie robił coś swojego. Szczególnie niebezpieczną sytuacją jest brak jakiegokolwiek celu. Nie będzie tu wówczas miejsca na korzystne efekty, jakie przynoszą Sprinty. Nie da się ustalić Celu Sprintu, a praca zespołu będzie miała charakter mechaniczny. Brak złożonego problemu do rozwiązania Złożony problem to np. wypuszczenie na rynek nowego produktu lub nowa, bardziej innowacyjna wersja już istniejącego produktu. Przy starcie projektu, zespół jeszcze nie wie, jak do niego podejdzie, jak rozwiąże to zadanie. Jeśli brak jest takiego złożonego problemu, a zespół wykonuje powtarzalne czynności i zajmuje się powtarzalnymi, sprocedurozowanymi czynnościami to Scrum się nie sprawdzi, ponieważ nie wniesie żadnej wartości dodanej.  Gdy wszystko jest przewidywalne i proste to wdrażanie mechanizmu wydarzeń scrumowych będzie tylko stratą energii i czasu zespołu. Nie ma tu co nas zaskoczyć i przykładowo Przegląd Sprintu będzie tylko spotkaniem czysto formalnym czy statusowym.  Brak kandydata na Product Ownera Taka osoba powinna być reprezentantem potrzeb, reprezentantem biznesu, reprezentantem interesariuszy. Dobrego Product Ownera cechuje decyzyjność, która w wielu organizacjach wiąże się z pewnego rodzaju autorytetem czy zaufaniem całej organizacji do tej osoby.  Rola Product Ownera jest na tyle krytyczna w Scrumie, że bez niego mogą pojawić się spore problemy i kłopoty. Brak samodzielności i autonomiczności zespołu Scrum się nie sprawdzi, gdy zespół nie ma zapewnionej autonomiczności i samodzielności, przez co nie jest on w stanie dostarczyć działającej wersji produktu.  Może to wynikać z braku wszystkich niezbędnych kompetencji w zespole. Przykładowo w produkcie cyfrowym, zespół składa się z developerów od frontendu i backendu, ale brak w nim testerów, którzy stanowią odrębny zespół. Podobnie może być, gdy produkt składa się z różnych komponentów, za które odpowiedzialne są różne zespoły. I tu znów, żaden z tych zespołów nie dostarczy gotowej, działającej wersji produktu. Przykładem bardziej biznesowym będzie zespół odpowiedzialny za nową wersję sklepu internetowego. Bez udziału np. osób z marketingu, które wiedzą jak zachować np. spójność całej marki, trudno sobie wyobrazić wdrażanie zmian. Spod punktu tego wymyka się sytuacja, gdy kilka czy kilkanaście współpracujących ze sobą zespołów – skalując się – są w stanie razem dostarczyć działający produkt. Istotna jest wtedy Definicja Ukończenia, wspólna dla wszystkich zespołów, które razem dostarczają przyrost. Natura pracy nie wymaga współdziałania w zespole W sytuacji, gdy zadania wykonywane przez członków zespołu mogą być wykonywane całkowicie samodzielnie, bez potrzeby synchronizacji się z pozostałymi osobami, to Scrum także nie ma racji bytu. Ludzie nie będą zaangażowani w działanie zgodne z elementami Scruma, a np. Codzienne Scrumy szybko zamienią się w nudne statusy. Najwięcej wartości z pracy w Scrum

Jesteśmy niemalże pewni, że znasz sytuację, w której Twój zespół miał za dużo projektów. Wszyscy są bardzo zapracowani, a spodziewanych efektów jak nie było, tak nie ma. Niektóre osoby pracują przy kilku projektach jednocześnie. Ekspert z danej dziedziny nie wyrabia się z pracą. Czasami trzeba zwrócić komuś uwagę, że projekt powinien być na innym etapie – z czym macie problem? Mamy dla Ciebie pięć porad na to, co możesz zrobić, kiedy w firmie jest za dużo inicjatyw jednocześnie. Porządny Agile · #067 – Mamy zbyt wiele projektów, co robić? Spis treści Dlaczego duża liczba projektów może być problemem?Co zrobić, gdy toczy się zbyt wiele projektów jednocześnie?FAQ: Mamy zbyt wiele projektów, co robić?📄Transkrypcja podcastu „Mamy zbyt wiele projektów, co robić?” Dlaczego duża liczba projektów może być problemem? Liczba projektów realizowanych w Twojej firmie staje się problemem? Pracownicy są przytłoczeni zadaniami, a ich efektywność spada? Jak zatem poradzić sobie z nadmiarem projektów i zapanować nad pogłębiającym się chaosem? Jest to istotny problem, ponieważ w sytuacji, gdy toczy się zbyt wiele projektów nie tylko pracownicy są mniej efektywni, ale także projekty nie posuwają się do przodu, a to dodatkowo wpływa negatywnie na zespół.  Może to też doprowadzić do sytuacji, że stracimy wyspecjalizowanych w konkretnych obszarach ekspertów, których zazwyczaj jest za mało. Kiedy toczy się wiele inicjatyw, są oni często zaangażowani w różne projekty i działania, stają się wąskimi gardłami w organizacji, przestają wyrabiać się z pracą, a presja na nich wywierana może skłonić ich do zmiany organizacji. W tym artykule przedstawimy Ci sprawdzone przez nas rozwiązania, wykorzystywane przez nas we własnej pracy, na to jak uporać się z nadmiarem toczących się inicjatyw.  Nim przejdziemy do tych rozwiązań to jedna ważna uwaga. Pisząc o projekcie czy inicjatywie mamy na myśli wszystkie te rzeczy, które są realizowane poprzez konkretne zespoły zwinne, np. pomysł na produkt, pomysł na ficzer, etap rozwoju produktu, element Backlogu Produktu.  Co zrobić, gdy toczy się zbyt wiele projektów jednocześnie? 1. Inwentaryzacja toczących się inicjatyw Polega to zebraniu w jednym konkretnym miejscu wszystkich toczących się inicjatyw, projektów, czy działań, po to, aby uzyskać wspólny obraz tego, co tak naprawdę aktualnie się dzieje. Możesz to zapisać w formie cyfrowej lub np. na tablicy ściennej w biurze. Głównym celem tego ćwiczenia jest umożliwienie całej organizacji zobaczenie na własne oczy, jak konkretnie wygląda aktualny stan etapu “in progress”.  Warto to zrobić, ponieważ jedną z przyczyn, dla których dzieje się za dużo rzeczy jednocześnie, jest to, że wiele osób (np. zarząd) nie ma świadomości o niektórych inicjatywach.  Ponadto taka inwentaryzacja bardzo często w praktyce doprowadza do istotnej refleksji i uświadomienia sobie ile rzeczy, robimy w tym samym czasie. 2. Wizualizacja postępu prac Po wykonaniu inwentaryzacji toczących się inicjatyw warto przeprowadzić wizualizację postępu prac na jeden z dwóch sposobów: w przypadku, gdy inicjatywy w naszej organizacji odbywają się w podobny i mają powtarzalny schemat możemy zwizualizować jakieś standardowe kroki postępu, np. najpierw składamy ofertę do klienta, potem odpowiadamy na zapytania, a w kolejnych krokach realizujemy kontrakt i wykonujemy czynności zamykające, w przypadku, gdy patrzymy na projekt z perspektywy rzeczy do zrobienia w celu uzyskania oczekiwanego efektu, a miarą jest czas czy budżet, wizualizacja może mieć formę liczby wykonanych czynności do wszystkich zaplanowanych, np. przeprowadziłem 5 z 8 zaplanowanych szkoleń to, jestem w 5/8 postępu realizacji tej konkretnej inicjatywy. Wizualizacja postępów pozwala zobaczyć, jak blisko końca jesteśmy i jak dużo jest jeszcze do wykonania.  Wykonanie tego ćwiczenia może być sporym zaskoczeniem, że pewne rzeczy jeszcze nie są skończone, albo dlaczego tak długo znajdują się w jakimś tam konkretnym etapie, bo np. oczekują na jakąś decyzję zewnętrzną. Oczywiście indywidualne rozmowy o postępie prac oraz maile z podsumowaniem spotkania statusowego są ważne, ale docierają tylko do części osób. Ponadto samo wysłanie maila nie jest gwarancją, że ktoś tę informację przyswoi. Natomiast takie wizualizowanie na poziomie globalnym, pokazuje, jak jest na poziomie całej organizacji. To trochę takie łączenie kropek. W rezultacie może dojść do sytuacji, że ktoś, kto normalnie nie miałby dostępu do statusu jakiejś inicjatywy czy projektu, nagle dowiaduje się, że ona jest w stanie X. A ten stan X ma negatywny wpływ na jakiś drugi projekt, który toczy się w innej części organizacji.  3. Limitowanie ilości równoległych prac To moment, w którym wiemy ile mamy rozpoczętych inicjatyw i na jakim są etapie, dzięki czemu jesteśmy w stanie zastanowić się  nad naszymi zdolnościami przepustowym do realizowania pracy.  Każda organizacja ma tę przepustowość na innym poziomie, jednak

Nie popełniaj tych błędów! Dowiesz się, z jakimi problemami najczęściej borykają się Zespoły Scrumowe. Dla każdego z nich przygotowaliśmy po trzy pomysły jak ich uniknąć. Zawarte w nagraniu rady wynikają z naszego doświadczenia i zostały przez nas sprawdzone podczas wsparcia wielu zespołów w wielu organizacjach. Porządny Agile · #066 – Najczęstsze problemy Zespołów Scrumowych W naszej praktyce pracy konsultanckiej spotykamy się z różnymi problemami Zespołów Scrumowych. Pięć z nich pojawia się najczęściej i na nich się dziś skupimy, podając jednocześnie po 3 rozwiązania dla każdego z osobna.  Spis treści 5 najczęstszych problemów Zespołów ScrumowychFAQ: Najczęstsze problemy Zespołów Scrumowych📄Transkrypcja podcastu „Najczęstsze problemy Zespołów Scrumowych” 5 najczęstszych problemów Zespołów Scrumowych 1. Niedotrzymywanie terminów Obiecywanie terminów, które są potem przekraczane, wiąże się z brakiem planu działania. Stąd też niezwykle ważne jest przygotowanie planu pracy w zespole. W ramach planowania Sprintu ustalić należy nie tylko jego celu, zakres realizowanych prac, ale także określenie sposobu pracy, odpowiedzialności za poszczególne zadania i zależności, zarówno między zadaniami, jak i osobami je realizującymi. Tworząc taki plan pracy, można od razu zauważyć, które rzeczy są niewykonalne, bo przykładowo jedna osoba jest zbyt przeciążona zadaniami. Łatwiej też określić realistyczne terminy realizacji poszczególnych zadań. Z planowaniem wiążę się druga wskazówka pomagająca dotrzymać obiecane terminy. Jest nią korzystanie z danych historycznych przy tworzeniu planu. Poprzez dane historyczne mamy na myśli: wcześniejsze rezultaty i wyniki, czy liczba zrealizowanych zadań. Z kolei jeśli zespoły korzystają z systemów estymowania relatywnego, to warto podsumować Story Pointy. Określając ile zadań realnie jesteśmy w stanie zrealizować można skorzystać z techniki Yesterday Weather. Polega ona po prostu na spojrzeniu na ostatni wynik Sprintu i na tej podstawie dobranie liczby elementów, które chcemy zrealizować w nadchodzącym Sprincie.  Zdarza się tak, że terminy nie zostają dotrzymane ponieważ podjęta została praca, która jest nieprzygotowana do realizacji, albo też niewystarczająco znana zespołowi. Stąd też trzecią radą w tym temacie jest inwestycja czasu w Refinement. Całym zespołem warto poświęcić pewnie procent czasu w trybie ciągłym na doskonalenie Backlogu Produktu, szukanie pełnego zrozumienia produktu, budowanie kryteriów akceptacji, rozpisywanie elementów na drobniejsze kawałki.  To właśnie niewystarczająca znajomość produktu często powoduje, że zespół nie potrafi dobrze rozplanować pracy i nie wyrabia się z terminami. Refinement, który wraz z Retrospektywą, są najczęściej pomijane w celu zyskania czasu, mogą prowadzić do błędnego koła ratowania terminów i ciągłego stresu w zespole. Szczegółowo o technikach Refinementu mówiliśmy w 9 odcinku naszego podcastu, który możesz posłuchać tutaj.  2. Błędy i awarie po wdrożeniu Drugim najczęstszym problemem, z którym się spotykamy, są sytuacje, w których po wdrożeniu pojawia się mnóstwo błędów i awarii, także takich, które blokują dostęp do produktu.  W tej sytuacji radzimy zdefiniować oraz przestrzegać Definicji Ukończenia.  Pierwszym krokiem w tym celu jest zdefiniowanie dokumentu, czyli miejsca, w którym będą spisane konkretne ustalenie przedyskutowane wewnątrz zespołu. Dzięki temu mamy jasność, że wszyscy zgadzają się na to, na co się umawiamy. Kolejny krok, już trudniejszy,  to przestrzeganie Definicji Ukończenia w praktyce. Pomóc w tym może umieszczenie Definicji Ukończenia w widocznym dla wszystkich miejscu, np. jej wydrukowanie i przywieszenie na ścianie lub umieszczenie jej w naszym narzędziu do zarządzania zadaniami. Istotne jest też przestrzeganie dyscypliny i zobowiązanie zespołu do utrzymywania pewnego, powtarzalnego standardu. Zmniejszy to pokusę odpuszczania sobie jakiś drobnych testów czy poprawienia błędów, które się potem piętrzą i prowadzą do awarii.  Drugą radą jest korzystanie z konkretnych, zwinnych praktyk programistycznych, takich bardziej technicznych. Zaliczyć tu możemy np. automatyzowanie pracy, ciągła integracja i refaktoryzacja kodu. Trzecią radą jest częstsze wdrażanie mniejszych kawałków produktu. Związane jest to, z tym że zwykle jest tak, że im większy kawałek produktu chcemy udostępnić naszym użytkownikom, tym większa jest szansa, że zabraknie nam czasu, żeby przetestować całość przed oddaniem do użycia. Dlatego dobrą praktyką jest dzielenie sobie pracy na małe kawałki. Pozwala to na szybsze stworzenie zmiany i szybsze jej przetestowanie. Szybciej też otrzymamy informację zwrotną i recenzję w przypadku procesów w stylu Code Review. 3. Rozczarowujące efekty pracy Problem ten rozpatrujemy z perspektywy biznesowej, w której powstał produkt i nie przekłada się to na wyniki biznesowe, ani na zadowolenie użytkowników. Pierwszym rozwiązaniem jest zapewnienie kontekstu bizneso

Dobrze przemyślane i zrealizowane szkolenie przynosi wymierne efekty. Co zrobić, żeby dobrze organizować szkolenia? Spędziliśmy w salach szkoleniowych, zarówno tych prawdziwych, jak i on-line, wiele godzin. Na podstawie tych doświadczeń podpowiemy Ci, o czym trzeba pomyśleć, żeby wszystko przebiegło sprawnie. Mamy dla Ciebie 10 konkretnych porad, dzięki którym planowane szkolenie przyniesie Ci zaplanowany efekt. Porządny Agile · #065 – Jak dobrze organizować szkolenia? Podzielimy się z Tobą naszymi obserwacjami związanymi z organizacją szkoleń, bazując na doświadczeniach. Byliśmy zarówno trenerami swoich zespołów zwinnych, liderami transformacji całych organizacji, jak i prowadzącymi szkolenia w firmach u naszych klientów. Co poruszamy w tym materiale? Sprawdź spis treści: Spis treści Co może się stać, gdy szkolenie zostanie źle zorganizowane?10 wskazówek jak dobrze zorganizować szkolenieFAQ: Jak dobrze organizować szkolenia?📄Transkrypcja podcastu “Jak dobrze organizować szkolenia?” Co może się stać, gdy szkolenie zostanie źle zorganizowane? nie uzyskasz efektu, który zakładasz osiągnąć, poniesiesz koszty, które się nie zwrócą, uczestnicy mogą być sfrustrowani i mieć poczucie straconego czasu 10 wskazówek jak dobrze zorganizować szkolenie Jak zatem zapobiec wyżej wspomnianym problemom? Sprawdź poniższą listę rekomendację na temat tego, jak dobrze zorganizować szkolenie dla zespołów: Traktuj szkolenia, jako część większej zmiany Ustal spodziewany efekt szkolenia Przemyśl skład grupy szkoleniowej Zadbaj o wyrównanie wiedzy u wszystkich członków zespołu Zorganizuj szkolenie, gdy będzie ono faktycznie potrzebne Wybieraj szkolenia od praktyków Szkolenie nie zaczyna się pierwszego dnia na sali Pomóż uczestnikom skupić się na zdobyciu wiedzy Zapewnij jakość Potraktuj szkolenie jako okazję do refleksji i wdrażania usprawnień Poniżej rozwijamy co mamy na myśli pod poszczególnymi rekomendacjami. 1. Traktuj szkolenia, jako część większej zmiany Szkolenia są zazwyczaj tylko fragmentem większej koncepcji lub szerszego pomysłu na kierunek rozwoju firmy. Mają one za zadanie uzupełnić wiedzę, która potem zostanie przełożona na praktykę. Są one więc pewnym punktem, po którym następuje kolejny element procesu zmiany.   Lider organizacji lub zespołu albo lider transformacji zwinnej organizując szkolenie, powinien zaplanować po nim konkretne działania wprowadzania w życie zmian. Mogą one mieć na przykład postać spotkania, na którym zapyta uczestników szkolenia o kilka spraw. O to, czego się nauczyli, jak wykorzystają zdobytą wiedzę i jakie mają przemyślenia.  Świetnie się tu też sprawdzi zatrudnienie szkoleniowca w roli mentora, który da członkom zespołów merytoryczne wsparcie po szkoleniu. W ramach takiego wsparcia wyłapie on błędy, podpowie co można robić lepiej. Często dzięki takiej pacy mentorskiej on zmniejszy napięcie związane z tym, że zespół stosuje daną technikę pierwszy raz. Trener pomaga wystartować i zacząć używać nowo zdobytej wiedzy w życiu zawodowym. Dzięki temu szkolenie będzie mogło spowodować faktyczną zmianę w sposobie funkcjonowania zespołów, a nie być jedynie “sztuką dla sztuki”. Można uniknąć traktowania szkolenia jako sposobu na wyłącznie wydanie istniejącego budżetu szkoleniowego.  Nie oczekuj jednak od trenera, że w ciągu jednego-dwóch dni szkoleniowych zespoły opanują wszystko i będą pracować zgodnie ze zdobytą wiedzą. Część rzeczy może być źle zrozumiana, ponadto każdy członek zespołu ma swoje nawyki. By nastąpiła trwała zmiana nawyków, niezbędna jest praktyka i konkretne działania. Oczywiście część warsztatowa szkolenia wprowadzi ćwiczenia praktyczne (np. techniki prowadzenia Retrospektywy), ale nigdy nie będą one pełnym odwzorowaniem rzeczywistości. 2. Ustal spodziewany efekt szkolenia Bardzo łatwo jest wpaść w pułapkę wybierania szkoleń z katalogu. Najpierw nazwij potrzeby Twojej organizacji (lub danego zespołu) i dopiero na tej bazie dobieraj konkretne szkolenia.  Sami spotykamy się z sytuacjami, kiedy klient zgłasza się do nas i chce zamówić konkretne szkolenie, na przykład z zaawansowanej zwinności. Po dłuższej rozmowie często okazuje się, że w organizacji klienta nie ma usprawnień, nie ma adaptacji produktu, a Codzienny Scrum to zwykły status meeting. W tym przykładowym przypadku uważamy, że należy najpierw wyprostować podstawy, zanim przejdzie się do szkolenia zaawansowanego Agile’a. Zdarza się też, że klient zamawia u nas szkolenie z danego obszaru. Po krótkiej rozmowie staje się jasne, że lepszy będzie dla niego program mentoringowy albo odpowiednio dopasowane spotkania konsultacyjne.  Dlatego bardzo ważne jest, aby określić, jaki efekt organizacja potrzebuje uzyskać. Dopiero po tym kroku porozmawiać z potencjalnym dostawcą, aby pomógł nam wybrać odpowiednie działanie wspierające. Gotowe szkolenia z katalogu, pomimo iż wyglądają atrakcyjnie, mogą nie odpowiadać na faktyczne potrzeby. 3. Przemyśl skład grupy szkoleniowej Warto poświęcić ch

Jakie cechy posiadają najlepsze zespoły? Przez lata pracy wyrobiliśmy sobie nasz punkt widzenia na to, czym charakteryzują takie zespoły. Poznaj pięć atrybutów doskonałych zespołów, które według nas są najważniejsze. Nie zabraknie też rekomendowanych i sprawdzonych praktyk, jak budować takie zespoły. Ten odcinek może być dla Ciebie inspiracją w dążeniu do tego, żeby Twój zespół stał się idealny. Porządny Agile · #064 – Cechy najlepszych zespołów Spis treści Wspólny celZaufanieBliska współpracaUsprawnianie sięBezpieczeństwo emocjonalne Transkrypcja podcastu „Cechy najlepszych zespołów” Atrybuty zespołów według Porządnego Agile’a Gdy myślimy o zespołach, często wykraczamy poza perspektywę zawodową. Wiele osób ma poza pracą pasje, które realizują właśnie w zespołach, w grach, sporcie, żeglarstwie, rekonstrukcjach historycznych czy działalności społecznej. W takich miejscach powstają silne zespoły. Ich członków łączy wspólne zaangażowanie, pasja i dobrowolność udziału. Poświęcają swój czas i wkładają emocje w to, co robią. W pracy często brakuje części z tych elementów. Funkcjonujemy w grupach ludzi, w dość przypadkowych konfiguracjach. Zespół projektowy powołano, bo akurat byliśmy dostępni. Trafiliśmy do tej samej jednostki organizacyjnej, mamy wspólnego lidera czy kierownika, ale to nie oznacza, że tworzymy zespół. A już na pewno nie oznacza, że jest to zespół silny. Z naszą wspólną obserwacją dobrze koresponduje wniosek, że takie zespoły nie powstają automatycznie. Nie tworzą się przez samo powołanie, fizyczne zgromadzenie ludzi czy nadanie im jednej nazwy. Trzeba im pomóc się ukształtować.  Wspólny cel Zespół w organizacji, czy to projektowej, czy będącej częścią większej struktury, zazwyczaj powoływany jest w konkretnym celu. Z perspektywy zarządzania ten cel bywa jasny i oczywisty. Nie oznacza to jednak, że wszystkie osoby w zespole rozumieją go tak samo. Wspólne zrozumienie jest niezbędne, aby precyzyjnie określić zasady działania, kierunek, w którym zmierzamy, oraz to, co ma zostać osiągnięte. Tylko wtedy nie pojawią się żadne wątpliwości, nawet najmniejsze, co dokładnie robimy i dlaczego. Równie istotne jest to, by cel miał znaczenie dla samego zespołu. Jeśli jest zupełnie nieistotny, abstrakcyjny albo zbyt odległy, trudno oczekiwać realnego zaangażowania. Zespół nie rzuci się do działania, jeśli nie widzi sensu ani wpływu tego celu na swoją pracę. Dlatego warto zadbać o to, by cel był konkretny, osiągalny i możliwy do przełożenia na codzienne działania. Tylko wtedy może stać się czymś, co spaja zespół i wzmacnia wspólne działanie.W wielu organizacjach cel zespołu bywa mylony z zakresem zadań. Zamiast wspólnego, znaczącego celu, zespoły koncentrują się na czynnościach operacyjnych:  wysyłaniu maili, sprawdzaniu określonych kroków w procesie, tworzeniu oprogramowania czy przygotowywaniu kreacji reklamowych. To jednak nie są cele zespołu – to jego zadania. Może się nawet zdarzyć, że zespół będzie miał nazwę odwołującą się do tych czynności, co tylko utrwali to mylne przekonanie. Prawdziwy cel powinien wykraczać poza operacyjny opis obowiązków i nadawać sens codziennej pracy. Zadaniem lidera, ale też odpowiedzialnością całego zespołu jest zdefiniowanie, dlaczego ta praca ma znaczenie. Co wnosi do firmy? Jaką wartość tworzy dla organizacji, a może nawet szerzej  dla klientów lub społeczeństwa? Warto uważać, by nie wpaść w pułapkę zawężonego myślenia, że jedynym sensem działania jest powtarzanie określonego kroku w procesie. Szersza perspektywa pozwala dostrzec nowe możliwości, innowacje, lepsze rozwiązania, zmiany, które mogą znacząco poprawić sposób działania zespołu, nawet jeśli na co dzień wykonuje powtarzalne zadania Zaufanie Z naszej perspektywy jednym z kluczowych atrybutów najlepszych zespołów jest zaufanie. To pojęcie bywa rozumiane na wiele sposobów, dlatego warto doprecyzować, co dokładnie mamy na myśli. Mówiąc o zaufaniu, myślimy przede wszystkim o poczuciu bezpieczeństwa i poufności. Chodzi o wewnętrzną pewność, że możemy swobodnie dzielić się przemyśleniami z każdą osobą w zespole, bez obawy, że nasze słowa zostaną wykorzystane przeciwko nam. Zaufanie to przekonanie, że członkowie zespołu tworzą środowisko, w którym można otwarcie mówić o swoich wątpliwościach, pomysłach czy obawach, bez ryzyka negatywnych konsekwencji. To właśnie ta niepisana zasada: co dzieje się w zespole (Las Vegas), zostaje w zespole w (Las Vegas), buduje przestrzeń do szczerości i współpracy.  Rozszerzając to, o czym wspomnieliśmy wcześniej, czyli zasadę Las Vegas, warto zauważyć, że właśnie dzięki takiemu podejściu możemy mówić otwarcie o tym, co naprawdę myślimy. Zarówno w kontekście samej pracy, jak i celu, który realizujemy, sposobu działania, wyzwań stojących przed nami lub tych, które mamy już za sobą. Zaufanie w zespole pozwala również na swobodę wypowiedzi na temat otoczenia,  umożliwia głośne nazywanie ryzyk, wyrażanie obaw i niezadowolenia. Dzięki temu nie c

Jak zrobić diagnozę stanu zwinności firmy? Dlaczego warto to robić? Podpowiadamy dziewięć sprawdzonych praktyk, które możesz samodzielnie zastosować i sprawdzić, w jakim momencie zwinności znajduje się Twoja organizacja. Taka ocena posłuży Ci jako punkt odniesienia, by sprawdzić, co jeszcze wymaga poprawy i ulepszenia. Jeżeli odnosisz wrażenie, że zwinność w Twojej organizacji utknęła w miejscu, to ten materiał jest dla Ciebie. Porządny Agile · #063 – Ocena stanu zwinności firmy Zobacz wersję wideo Materiał zakłada, że samodzielnie dokonasz oceny stanu zwinności w Twojej organizacji. Jeżeli potrzebujesz pomocy eksperta w takiej ocenie, sprawdź naszą ofertę diagnozy zwinności. Dokonamy analizy stanu obecnego, wskażemy miejsca do usprawnienia oraz zaproponujemy bardzo konkretne rekomendacje dalszych działań. Dodatkowe materiały Zasady stojące za zwinnym manifestem Artykuł o intuicyjnej zwinności 📄Transkrypcja podcastu „Ocena stanu zwinności firmy” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Jacek: W dzisiejszym odcinku będziemy rozmawiać o ocenie stanu zwinności firmy. Dla kogo jest ten odcinek? No przede wszystkim dla osób, które mają poczucie, że zmiana w organizacji, która się toczy, utknęła w miejscu, albo mają poczucie, że coś, co dobrze działało i wyglądało na obiecującą zmianę nagle popsuło się. To może być też taka potrzeba dodatkowego kopa. Jakiejś takiej nowej energii czy może też nowej interpretacji tego, co dzisiaj boli. Kuba: I taka ocena stanu zwinności firmy jest potrzebna. Dlaczego w ogóle warto zrobić coś takiego w organizacji? Wiele firm na jakimś etapie pracy w sposób zwinny, gdy upłynęły już te pierwsze momenty, pierwsze starty, pierwsze jakieś zamieszania, reorganizacje, łatwo osiada na laurach. Osiada na laurach, czyli przestaje już postępować zmiana. Nie ma już dalszego rozwoju. Te dokonane pierwsze działania prawdopodobnie dały jakieś pierwsze rezultaty i nie ma dalszych kroków. Nie ma realizacji jakiegokolwiek dalszego planu. Czyli stary plan na zmianę, na te pierwsze kroki nam się wyczerpał. Nie mamy nowego. Nie realizujemy dalej jakiejś wizji. Nie usprawniamy tego, co nam wychodzi w tych pierwszych krokach. Nie drążymy głębiej, jeśli mamy taką możliwość. Taka ocena stanu zwinności jest też potrzebna jako pewien punkt odniesienia. To, co powiedziałem przed chwilą, to była pewna taka spekulacja. I ta pewna spekulacja jest też bardzo życiowym przypadkiem, że wydaje nam się, że jest lepiej. Wystartowaliśmy jakieś zespoły zwinne, wystartowaliśmy jakieś konkretne praktyki, ale no nie zawsze jest ta wystarczająco głęboka refleksja, czy faktycznie jest lepiej i co jeszcze wymaga dalszej zmiany. Jacek: Do oceny stanu zwinności proponujemy dziewięć praktyk – narzędzi, praktyk. Te rozwiązania pogrupowaliśmy w trzy takie przystępne grupy. Trzy z tych rozwiązań są typowo związane z zespołami, które funkcjonują w ramach organizacji. Trzy rozwiązania uwzględniają grupę liderów zmiany osób, które są zaangażowane w to, żeby zmiana postępowała. I trzy narzędzia, to są narzędzia, które bazują na zaczerpnięciu z inspiracji zewnętrznej. Kuba, co mamy w tym wachlarzu praktyk, który dzisiaj przedstawimy? Kuba: Zacznę od pewnej praktyki, która wydaje mi się najbardziej banalna. Jest to checklista. Skorzystanie z jakiejś formy check listy na poziomie całej organizacji, na poziomie sumy wszystkich zespołów. Listy kontrolnej, która przez uzgodniony zestaw pytań sprawdzi, gdzie jesteśmy. I to jest oczywiście o wiele bardziej zniuansowane, niż tylko takie – skorzystaj z checklisty, no ale na jakimś takim ogólnym poziomie chodzi o to, żeby cała organizacja spróbowała sobie odpowiedzieć na te same pytania i na bazie tych odpowiedzi dokonać pewnej refleksji, wyciągnąć pewne wnioski. Prawdopodobnie powiedzieć sobie wprost, które rzeczy są w porządku, które rzeczy są zgodne z tym naszym punktem ustalonym odniesienia, a jakie rzeczy jeszcze wymagają usprawnień. I nieprzypadkowo mówię tutaj ustalony punkt odniesienia, bo taka check lista, no to to oddzielna rozmowa jest, którą z nich wybrać. Zacznę od chyba od najbardziej banalnego przypadku, jeśli na przykład konkretnie korzystamy z metody Scrum, no to istnieją, są dostępne check listy, które sprawdzają, no nazwijmy to zgodność ze Scrumem. To jeszcze nam nie do końca oceni stan zwinności firmy, ale da jakieś pierwsze przybliżenie. I tak, jak do zwinności firmy, moim zdaniem potrzebne jest o wiele, wiele więcej, niż tylko przestrzeganie Scruma, tak nieprzestrzeganie Scruma, jeśli się zgodziliśmy, że akurat to jest ta droga, którą chcemy postępować, no może być takim mocnym sygnałem – faktycznie musimy realizować Retrospektywy, tworzyć przyrost co Sprint, przestrzegać Definition of Done, posiadać Backlog Produktu. Kilka takich podstawowych aspektów Scruma, które no naprawdę, jeśli ich nie mamy, to prawdopodobnie tu jest coś do poprawy na takim dosyć podstawowym poziomie.  Jacek: Ja myślę, że

Wartość biznesowa bywa czasem buzzwordem, który często wypowiadany jest bez pokrycia i zastanowienia się. Wyjaśnimy zatem czym ona jest i jak podejść do jej używania. Z odcinka dowiesz się, jakie są przykłady miar wartości biznesowej.  Porządny Agile · #062 – Wartość biznesowa w agile Zobacz wersję wideo Sprawdź nasz webinar o dzieleniu elementów Backlogu Produktu na mniejsze elementy. Dodatkowe materiały Evidence‑Based Management – przewodnik po zarządzaniu opartym na dowodach 30 elementów wartości, które napędzają lojalność i wzrost biznesu North Star: Przewodnik po metryce, która wyznacza kierunek rozwoju produktu Drzewo możliwości: jak wizualizować ścieżki do celów produktowych 📄Transkrypcja podcastu „Wartość biznesowa w agile” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Kuba: Ostatnio pracowałem z Product Ownerami w firmie, którą wspieram i zatrzymaliśmy się w czasie tej pracy na dłużej w temacie wartości biznesowej. Ta rozmowa była na tyle inspirująca i jak się okazała też bardzo owocna, aż chcę to poruszyć też z Tobą i razem z Jackiem w tym nagraniu. Jacek: Generalnie pojęcie wartości biznesowej jest takim trochę buzz wordem. Bardzo często możemy usłyszeć, że wartość biznesowa jest najważniejsza, albo że Product Owner maksymalizuje wartość biznesową. Natomiast bardzo często jest to takie słowo, które pada trochę bez pokrycia, czasami bez zastanowienia się. Celem tego dzisiejszego odcinka jest zwrócić Twoją uwagę na to, czym wartość biznesowa jest i jak podejść do jej używania. Kuba: Warto zaznaczyć, że wartość biznesowa jako taka nie ma jakiejś ścisłej definicji. Często jest to dosyć ogólne pojęcie. My na potrzeby tego nagrania posłużymy się takim założeniem, że wartość biznesowa pokazuje nam, że zbliżamy się do założonego celu albo się do niego nie zbliżamy lub wręcz oddalamy. Czyli, innymi słowy, wartość biznesowa to jest jakaś charakterystyka poszczególnych elementów danego produktu, która pokazuje albo zbieżność, czy zgodność, czy zbliżanie się do tego, po co ten produkt istnieje. W mniejszym lub większym natężeniu lub niestety cofanie się od tego. I zacznijmy od tego, dlaczego w ogóle posiadanie wartości biznesowej, posługiwanie się nią, jest ważne dla zespołu zwinnego? Dlaczego jest to ważne? Jacek: Przede wszystkim trudno jest priorytetyzować, jeżeli nie mamy określonej wartości biznesowej elementów w Backlogu Produktu. No bo de facto nie mamy jakby do czego się odnieść. Tych elementów zwykle jest wiele. Jeżeli nie poddamy ich jakiejś ocenie, no to może się pojawić takie ryzyko, że będziemy te elementy robić w niewłaściwej kolejności, z punktu widzenia przybliżenia się do konkretnego celu biznesowego.  Kuba: Drugim powodem, dla którego wartość biznesowa może być potrzebna to jest już taki etap, gdy faktycznie zaczynamy dostarczać rozwiązanie. No i warto mieć jakąś wartość względem, której policzymy, jak to jednak nam wypadło. Czyli ten etap priorytetyzacji, o której Jacek przed chwilą mówiłeś, to jest taki etap zgadywania. Przewidywania. Takiego przypuszczenia, że coś nam poprawi sytuację w jakimś stopniu. Może już wiemy, w jakim dokładnie, a może tylko mamy przeczucie, że w dosyć mocnym. Natomiast, jeśli mamy konkretną definicję, jeśli posłużymy się konkretnymi mierniki, to tak post factum, czy w kolejnych etapach wdrożenia kolejnych przyrostów, możemy faktycznie sprawdzić na rynku, sprawdzić z klientem, z użytkownikiem, z odbiorcom końcowym, jak ten produkt polepszył się? W jakim stopniu? Jak jest ceniony? A może niestety ten negatywny przypadek – nic się nie poprawiło, albo wręcz pogorszyło. Czyli, no musimy mieć tą wartość biznesową i jakby mieć ją zdefiniowane i mieć ją powierzoną, by domknąć, czy dopiąć tutaj tę pętlę informacji zwrotnej, jak się nasze zamierzenia miały do tego, co faktycznie wyszło nam w praktyce. Jacek: I ostatnia rzecz, na którą warto zwrócić uwagę, to to, że rozmowa o wartości biznesowej buduje kontekst w zespole. Czyli pozwala ukierunkować pracę zespołu we właściwym kierunku i pozwala też osobom, które są w zespole – no mieć taki pewien punkt odniesienia i zrozumienie, dlaczego pewne rzeczy robimy? W którą stronę podążamy? No, a świadomość ta pozwala podejmować lepsze decyzje. Od takich małych decyzji, codziennie w trakcie pracy. Po większe decyzje, które przykładowo zespoły podejmują w trakcie sesji planowania nadchodzącej iteracji. Kuba: I tak, jak ja wspominałem w swoim punkcie, to oprócz tego planowania ten kontekst może też wracać, gdy już ten produkt żyje, jest długofalowo rozwijany. Rozmawiamy nie o konkretnych ficzerach, nie o konkretnych pomysłach, projektach – tylko o tym, że nasz produkt jest ciągle i ciągle lepszy. Ma jakiś sens biznesowy jego funkcjonowania. Chcemy też przytoczyć kilka przykładów miar wartości biznesowej, żeby też konkretnie uzmysłowić, jak może to wyglądać. Zacznijmy od pewnej listy, tak dosyć szybko wyliczonej, ale później przejdźmy do szczegółów

Rozprawiamy się z tezą, że w Agile nie chodzi o dowożenie więcej, taniej i szybciej. Zainspirował nas do tego Tomek Włodarek, pisząc to na swoim Twitterze. Zgadzamy się z tym. Niektórzy zakładają, że skoro jest zwinnie, to musi być więcej, taniej i do tego szybciej. Zastanowimy się, jaka jest ścieżka takiego myślenia. Do całości dorzucimy Ci jak zwykle garść naszych bardziej ogólnych przestróg. Porządny Agile · #061 – Agile = więcej, taniej, szybciej? Zobacz wersję wideo Dodatkowe materiały Efektywność Zespołu Scrumowego Koszty podejścia zwinnego Twitter Tomka Włodarka 📄Transkrypcja podcastu „Agile = więcej, taniej, szybciej?” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Jacek: Jakiś czas temu trafiliśmy z Kubą na tłit Tomka Włodarka i potraktowaliśmy ten wpis na Twitterze jako inspiracja. Zdanie, które zwróciło naszą uwagę, to było zdanie, które Tomek podzielił się taką myślą, że w agilu nie chodzi o dowożenie więcej, taniej i szybciej. I to sformułowanie będzie takim tłem dzisiejszego odcinka. Kuba: Odniesiemy się do tej o treści. Powiemy, dlaczego w Agile naszym zdaniem nie chodzi o dowożenie więcej, taniej i szybciej. Skomentujemy to co naszym zdaniem w agile chodzi i trochę pogłębimy tę myśl. I na końcu ukończymy pewną grupą przestróg o tym, że każde, nawet najbardziej poprawne uproszczenie, może nadal być pułapką podatną na przeinaczenie i błędne zrozumienie. Jacek: Do pewnego stopnia rozumiemy z Kubą, skąd w ogóle taki pomysł może się pojawić w czyjeś głowie, że zwinność może oznaczać czy więcej, czy taniej i szybciej. I odniesiemy się po kolei do każdej każdego z tych przymiotów, próbując dojść do tego, jaka jest ścieżka myślenia, która prowadzi do takich sformułowań oraz będziemy starali się wskazać ewentualne ziarenko prawdy. Kuba: Zaczniemy od więcej. Tu wydaje mi się, że z tym więcej jest przynajmniej między nami najmniej kontrowersji. Bo potrafię zrozumieć, że ktoś myśli, że podejście zwinne oznacza więcej, bo tak od kogoś usłyszał, tak może zapamiętał z jakiegoś case study innej firmy lub jakiegoś projektu, gdzie ktoś, kto opowiadał o takich korzyściach z podejścia zwinnego, miał na myśli to, że dzięki podejściu zwinnemu uzyskuje więcej wartości. Więcej wartości rozumianej jako wynik finansowy czy biznesowy. Więcej wartościowych rozwiązań, więcej wartościowych ficzerów. Więcej wartościowych elementów, ale bez nacisku na to, że sam fakt, że jest ich więcej, w sensie ciężarówka jest wypełniona bardziej piaskiem. Tylko że ten piasek jest bardziej wartościowy. Natomiast to jest akurat taki niuans, który bardzo łatwo umyka. No i jakby to tutaj pojawia się uproszczenie. Ci, którzy się chwalą, że podejście zwinne miało jakieś ich korzyści, mieli na myśli to, że jest więcej wartości. Ktoś, że tak powiem, przeoczył to drugie ze słów i zapamiętał, że to jest więcej. Jacek: Ta zdolność do zwiększonego wolumenu produkcji, że tak sobie to umiemy, ona faktycznie jest do uzyskania w zespołach, które pracując w zwinny sposób, między innymi poprzez lepsze skupienie, między innymi poprzez to, że zespoły są odblokowane na zasadzie jakiejś przeszkody, które stoją na drodze zespołu – są usunięte. Czyli przykładowo, jeśli mówimy o zespołach funkcjonujących w środowisku IT, to to mogą być jakieś środowiska, które działają, jak należy. Środowiska testowe, które w dobrym stopniu odwzorowują to co jest na produkcji, przez co zespół nie musi powtarzać pewnych czynności, które można byłoby wsadzić do kategorii marnotrawstwa. Więc w pewnym sensie to więcej jest możliwe do uzyskania w podejściu zwinnym i zwykle wynika to z szeregu pewnych małych usprawnień, które jak w końcu je zsumujemy, no to okazuje się, że zespół faktycznie jest w stanie w jakimś tam oknie czasowym dostarczać więcej. Kuba: I to więcej może też być zbudowane na takim wrażeniu, że pewne rzeczy, które do tej pory w ramach danej organizacji albo były zupełnie zablokowane, albo się nazbyt potocznie wlokły, czyli przyciągały się realizacje, przedłużały. No, jeśli dobrze je wpuścić w jakieś takie zwinne tryby z zaangażowanym zespołem, z jakimś takim konkretnym naciskiem na krótkie małe kroki, no to może się okazać, że te rzeczy się wreszcie ruszyły, jeśli były zupełnie zablokowane, albo trochę przyspieszyły, czy odblokowały. I tak patrząc na pryzmat, co jest realizowane, no to jest wrażenie, że jest tego więcej. Zaczyna się ruszać. Zaczynają być wdrożenia. Zaczynają się kończyć projekty. No i tutaj trochę tak polemizujemy z tym, bo też ostatnia myśl, która mi przychodzi do głowy w temacie więcej, to też jestem mocno przekonany o tym, że zwłaszcza w średnim okresie, czyli nie natychmiast po rozpoczęciu pracy w sposób zwinny, ale w dłuższym okresie, tak po kilku miesiącach, może po kilku kwartałach, spodziewałbym się, że zgrany zespół bez patrzenia na jakiekolwiek inne wymiary będzie realizował trochę więcej pracy. Wcale nie aż tak wiele więcej. Nie myślę tutaj jeszcze o jakichś takich obietnicach, o

Jak poprawiać efektywność Zespołu Scrumowego? Temat do rozmowy podsunęła nam nasza słuchaczka Karolina, wielkie dzięki! Dowiesz się, jak my rozumiemy efektywność i czym ona jest. Mamy kilka sprawdzonych porad, które pomogą Ci na nią wpłynąć. Dorzucamy do tego jeszcze różne, konkretne praktyki, aby temat efektywność zamknąć kompleksowo. Porządny Agile · #060 – Efektywność Zespołu Scrumowego Zobacz wersję wideo Dodatkowe materiały #051- Aktualizacja Przewodnika po Scrumie 2020 #057 – Jak zreorganizować zespoły? Prawdziwe przypadki Scrumowe – warszaty dla Scrum Masterów i Agile Coachów Start with why #010 – Product Discovery Mapy empatii – artykuł na Agile247.pl Story mapping – artykuł Jacka Story slicing patterns Impact mapping – artykuł na Agile247.pl Lean UX Non Violent Communication 📄 Transkrypcja podcastu „Efektywność Zespołu Scrumowego” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Kuba: W dzisiejszym odcinku opowiemy o efektywności Zespołu Scrumowego. Temat zaproponowała Karolina w odpowiedzi na nasz newsletter. Dzięki Karolina za całą listę propozycji. Spośród nich wybraliśmy to konkretne pytanie, czy tę konkretną propozycję. Pozwól, że przeczytam całą treść tego pytania, bo tutaj jest ważny smaczek. Pytanie brzmi. Jak wypełniać i realizować, jakimi narzędziami poza wielu velocity, capacity i tym podobne, odpowiedzialność za efektywność teamu w roli Scrum Mastera. Jacek: Plan na dzisiejszy odcinek jest taki, że na początku definiujemy, czym jest efektywność. Następnie podzielimy się naszymi poradami, jak można wpłynąć na efektywność. I na koniec dołożymy do tego już bardzo konkretne praktyki, które mogą pomóc Ci w tym temacie. To Kuba, jak jest z tą efektywnością w Scrumie? Kuba: I to jest dobre pytanie, bo ta efektywność pojawia się w najnowszej aktualizacji Scrum Guide’a. Opowiadaliśmy w 51. odcinku o tym, jak zmienił się Scrum Guide, czy jak się zmieniły wytyczne scrumowe w najnowszej wersji. I tam m.in. pojawia się bardzo jasno wprost powiedziane, że to Scrum Master jest accountable, czyli odpowiedzialny, ale w tym istotnym zniuansowanym znaczeniu, jest odpowiedzialny za to, żeby Zespół Scrumowy był efektywny. I tutaj musimy zacząć od takiego trochę językowego kawałka, czyli tej definicji, o której Jacek powiedział w planie odcinka. Bo tutaj dwa smaczki są. Jedna sprawa to jest właśnie ta odpowiedzialność Scrum Mastera. Czyli Scrum Master sprawia, że te rzeczy się dzieją. Natomiast oczywiście wspierany jest przez cały Zespół. Natomiast jeszcze ważniejsze niuans jest, w definicji czy w rozumieniu słowa efektywność. Intuicyjnie, bez zaglądania w definicje żadne, możemy mieć czasami złe wyobrażenie i często się z tym spotykam w różnych Zespołach, że to znaczenie słowa efektywność kojarzy się bardziej z produktywnością, z realizacją jak największej ilości pracy. Natomiast to nie jest tak, efektywność to nie jest właśnie ilość pracy, którą wykonujemy, tylko to jest wartość tego, co dostarczamy. Stąd, jeśli byśmy tutaj rozebrali tą definicyjną część efektywności czy odpowiedzialności za efektywność Zespołu Scrumowego, no to Scrum Master sprawia czy doprowadza, wspiera do tego, żeby wartość pracy, którą wykonuje cały Zespół Scrumowy, była jak no najlepsza. Przede wszystkim jakaś konkretna, ale też najlepiej jak najbardziej rosnąca. Jacek: Czyli tutaj generalnie, no na pewno rozczarujemy osoby, które ucieszył ten zapis w najnowszym wydaniu Scrum Guide’a, że Scrum Master teraz będzie, przerysuję oczywiście, stał nad ludźmi i powodował, że będą szybciej pracować. No nie o taką efektywność chodzi. Bardziej chodzi nam o to, żeby Zespół robił nie tyle szybko rzeczy, co żeby robił rzeczy właściwe. Czyli takie rzeczy, które przybliżają nas do osiągania konkretnych celów biznesowych. Kuba: I zwróćmy uwagę, że tutaj w tych osiąganych celach biznesowych nie ma słowa o velocity, czy capacity, więc tutaj jednak zrobimy korektę do tego pytania oryginalnego, które zainicjowało, czy zainspirowało nas do nagrania, że akurat na przykład velocity liczona jako Story pointy dostarczane przez Zespół, albo ilość ficzerów dostarczana przez Zespół, czy jakakolwiek miara przewidywalności Zespołu, realizacji Celu Sprintu, to wszystko nie są miary efektywności. To są miary też istotne. To są miary procesowe pokazujące, jak Zespół pracuje. Natomiast to nie są miary efektywności. I de facto można nawet, by powiedzieć, że nie mają z efektywnością w sumie nic wspólnego. Tylko żebyśmy nie mieli tutaj złego skojarzenia. Te rzeczy związane z wydajnością procesu, przewidywalnością procesu też są istotne. No bo jeśli na przykład Product Owner, czy firma, czy sam Zespół nie może polegać zupełnie na swoim procesie, Zespół czasem coś robi, czasem czegoś nie robi, czasem robi więcej, czasem robi zupełnie nic, albo bardzo mało. No to tutaj to też jest duży kłopot i on może czasami być jeszcze bardziej fundamentalny, niż to, jak wartościowe jest to, co

Jak Agile Coach może pracować nad zmianą? Jak się do tego zabrać? Co robić i w jakiej kolejności? Odcinek jest efektem rozmowy Kuby ze znajomą Scrum Masterką i postanowiliśmy pogłębić ten temat. Chcemy Ci pokazać, jak osoba zaangażowana w zmianę może decydować, co będzie zmieniane, jakie są priorytety. Nie traktuj naszych porad jako gotową instrukcję, ale jako inspirację do działania. Porównaj sobie to, jak pracujesz, z tym, co mówimy w tym odcinku. Porządny Agile · #059 – Praca Agile Coacha nad zmianą Zobacz wersję wideo Dodatkowe materiały Jak reorganizować zespoły? „Start with Why” – Simon Sinek 📄 Transkrypcja podcastu „Praca Agile Coacha nad zmianą” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Kuba: W dzisiejszym odcinku poruszamy temat pracy Agile Coacha nad zmianą. Temat jest zainspirowany konkretną rozmową, którą niedawno przeprowadziłem w ramach pracy w pewnej firmie, w której jestem obecnie zaangażowany jako Agile Coach. I de facto miałem rozmowę nie z Agile Coachem, a ze Scrum Masterką, która ma sporo do zrobienia. Ma wyobrażenie mnóstwa pracy do wykonania i odbyliśmy bardzo fajną rozmowę na temat tego, co w ogóle zrobić, w jakiej kolejności, według jakich priorytetów. Jak się zabrać za to co jest do zrobienia w ramach jej zespołu i otoczenia tego zespołu? I to jest o tyle ciekawa historia, że na bazie tej rozmowy – po pierwsze uporządkowałem sobie ten temat i myślę, że z Jackiem sobie też przedyskutujemy ten wątek, po to, żeby powiedzieć i pokazać jak przykładowo Scrum Master, Agile Coach albo osoba zaangażowana w zmianę może poprowadzić temat zorganizowania sobie decyzji na temat tego, co będzie zmieniane, czy co będzie moim priorytetem pracy. Jacek: Nie mamy aspiracji, żeby to, co powiemy, stało się jakimś takim gotowcem. Bardziej to był – jakby to, co usłyszysz w odcinku, to jest efekt naszej rozmowy, gdzie zastanowiliśmy się, jak podchodzimy do zmiany. Trochę wyszliśmy od tego, jak zarządzamy priorytetami, ale okazało się, że temat jest trochę szerszy, niż same priorytety. Stąd skupimy się na takim modelu pracy nad zmianą. Jak w ogóle odnajdujemy się jako konsultanci, czy Scrum Masterzy, czy Agile Coachowie, czy liderzy transformacji w sytuacji, w której musimy podejmować jakieś konkretne decyzje związane ze zmianą. Kuba: I chcemy opowiedzieć, jak my się do takich rzeczy zabieramy. Chcemy trochę podzielić się też przemyśleniami w tej kwestii. Potraktuj to wszystko, co w tym odcinku będzie zawarte, jako inspiracje. Porównaj sobie do tego, jak postępujesz się w tej sytuacji. Może masz jakiś inny model podejścia? Może nie robisz tego w sposób świadomy? Myślę, że to jest coś na zasadzie porównania i takiej wspólnej rozmowy z Jackiem o tym pogadamy. Posłuchaj też i pomyśl, jak ty to robisz. Zaczniemy w nagraniu od takiej ogólnej koncepcji pracy nad zmianą, którą gdzieś tutaj z Jackiem ustaliliśmy, że w zasadzie według takiego modelu postępujemy. Są między nami niuanse. My spróbujemy tutaj pokazać trochę różnice, czy też takie możliwe różne podejścia do tematu. W drugiej części odcinka podsumujemy też takimi bardziej ogólnymi radami dla osoby, która nad zmianą czy to w swoim zespole, czy w swojej części firmy lub całej firmie pracuje. No i jaka jest ta ogólna koncepcja, tak jak sobie to uporządkowaliśmy, nazwaliśmy jakieś konkretne punkty? Pierwszy punkt, jaki przychodzi nam do głowy – absolutnie podstawowy, ważny, pewnie przewija się to przez wiele odcinków. Musimy zacząć od celu. Jacek powiedz coś szerzej. Jacek: No ten, cel tak generalnie, im dłużej z Kubą pracujemy w środowisku zwinnym, tym ten cel – tak patrząc historycznie na nasze rozmowy, on coraz bardziej zyskuje na wadze i dlatego też często o tym wspominamy. No, ponieważ pozwala nam jasno określić taki najbliższy horyzont, co tak naprawdę chcemy uzyskać. Żeby ustalić cel, trzeba zadać szereg pytań, które są ważne. No i odpowiedzi na te pytania. Im dłużej rozmawiamy, im głębiej schodzimy, próbując zrozumieć, dlaczego właśnie jakiś konkretny cel jest dla nas istotny, a inny jest mniej istotny, pozwala nam zrozumieć pewne motywacje, które stoją za podejmowaniem decyzji. I takie dobre przedyskutowanie, co jest celem, z jednej strony pozwala nam podejmować lepsze decyzje, bo rozumiemy, mamy kontekst, wiemy, dlaczego pewne rzeczy są istotne. Z drugiej strony taka rozmowa nad tym, jaki jest cel, no jest takim nazwijmy, to bezpiecznikiem, który upewnia nas, że po obu stronach jest zrozumienie tego, co jest ważne. No i pomaga to uniknąć jakiegoś rozczarowania. Mogłoby się okazać, że ktoś trochę inaczej zrozumiał to nasze takie dogadanie się, co jest istotne. My trochę inaczej, no i to może prowadzić to do niezadowolenia. No, generalnie po obu stronach. Kuba: Ja bym dorzucił do tego jeszcze taki wątek, że zwłaszcza jeśli Agile Coach ma do zrobienia, na przykład zmianę, transformację, uruchomienie podejścia zwinnego w swoim zespole, czy w swoim obszarze

Na co musisz uważać, kiedy tworzysz roadmapy w ujęciu zwinnym? Będziesz to wiedzieć, kiedy posłuchasz nagrania tego odcinka. Dowiesz się też, jakie odczuwamy wyzwania związane z roadmapami. Na bazie naszych wieloletnich doświadczeń, wgryźliśmy się w temat i przedstawiamy Ci najważniejsze problemy, pułapki, zagrożenia związane z roadmapami. Dodatkowo podsuwamy też kilka rozwiązań i alternatyw dla tych problemów. Porządny Agile · #058 – Roadmapy w agile Zobacz wersję wideo Dodatkowe materiały Zwinne projekty i produkty Product Discovery „Strategize” Romana Pichlera – recenzja książki Propozycja szablonu roadmapy od Romana Pichlera 📄Transkrypcja podcastu „Roadmapy w agile” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Jacek: Porozmawiamy dzisiaj o roadmapach, typowo w ujęciu zwinnym. Geneza tego odcinka jest taka, że bardzo łatwo jest trafić w Internecie na artykuły o tym, jak robić roadmapy. Natomiast z naszej perspektywy dosyć rzadko są to faktycznie wskazówki, które pomagałyby tworzyć takie roadmapy w środowisku zwinnym. Dlatego zebraliśmy z Kubą nasze przemyślenia w tym obszarze i zamierzamy się tymi przemyśleniami dzisiaj z Tobą podzielić. Kuba: W całym odcinku będziemy mniej mówić o definicji roadmapy, więc dosłownie superkrótko teraz powiem, co mamy na myśli. Roadmapa jest to takie narzędzie, ono jest używane w produkcie, ale jest też szerzej wykorzystywane to pojęcie. Roadmapa to pewien plan działania w pewnej perspektywie czasowej. W kontekście produktów to jest najczęściej roadmapa kwartalna, roadmapa półroczna lub roczna, pokazująca pewną perspektywę, pewne plany rozwoju danego produktu. W perspektywie zwinnej roadmapy są swojego rodzaju ogólniejszym ujęciem planu pracy, niż na przykład Backlog Produktu stosowany w Scrumie. Roadmapa to potrafi być kilka punktów pokazujących, gdzie zmierzamy z naszym produktem. Jaki mamy konkretny, taktyczny plan na jego dalszy rozwój. Więcej szczegółów na temat tego, jak konstruować, z czego się składa taka roadmapa, jaki może być jej szablon, opisane jest to wszystko u Romana Pichlera. Do którego mocno odsyłam, ponieważ tam temat jest wyczerpany. Link do tego materiału będzie w opisie odcinka lub na stronie. Gdyby interesował Cię temat głębiej, to ja też mocno Romana Pichlera polecam w postaci książki. Książka „Strategize”, którą swoją drogą też mam swój egzemplarz. Widać go u mnie na półce. Recenzowałem tę książkę jakiś czas temu na Agile247 i tam też trochę materiałów na temat roadmap jest. Natomiast w samym odcinku skupimy się na tym, żeby poopowiadać o tym, jakie czujemy wyzwania związane z roadmapami. Jakie obserwujemy w firmach, z którymi współpracujemy lub w firmach, w których funkcjonowaliśmy jeszcze, jako osoby pracujące w środku tych organizacji. Jakie pierwsze wyzwanie chcemy wymienić? Jacek: Pierwszy problem, który dostrzegamy z roadmapami, że one są bardzo często traktowane, jako już pewne konkretne zobowiązanie. Czyli scenariusz zwykle wygląda następująco, że osoba, która zarządza produktem, jest proszona najczęściej przez swoich zwierzchników, o przygotowanie roadmapy planu rozwoju produktu. Zwykle osoba taka wraca do zespołu. Konsultuje aspekty techniczne na zasadzie, kiedy pewne rzeczy mogły być zrealizowane. No i taki komplet informacji na zasadzie, kiedy zrobimy i kiedy to mniej więcej będzie, idzie w górę organizacji. Niestety te najczęściej podane konkretne daty, czy ramy czasowe do kiedy pewne rzeczy będą gotowe, no stają się zobowiązaniem. Czyli organizacja zaczyna rozliczać osobę odpowiadającą za produkt z tego, czy faktycznie te konkretne rzeczy, które na tej roadmapie się pojawiły, czy do tych konkretnych dat, które były deklarowane – zostały dostarczone. Kuba: Zanim wejdę w możliwe rozwiązania, to ja tutaj dorzucę, czy dołożę akcentu na to, co Jacek powiedziałeś, że rozliczanie jest chyba tutaj najbardziej niepokojące w roadmapach. Bo to, że roadmapa pokazuje pewne ambicje, pewne aspiracje, że jest jakąś formą planów, do których będziemy dążyć jako zespół, jako produkt, jako Product Owner, to jest dla mnie w porządku. Natomiast zaczyna się dla mnie kłopot, jak się zaczyna rozliczanie. Czyli wytłumacz się, wyjaśnij, dlaczego ta roadmapa nie została zrealizowana, nie została zrealizowana w całości, albo co gorsza – co do joty. W takim środowisku, czy w takiej perspektywie rozliczania takiej roadmapy – no pierwszy pomysł, który nam przychodzi do głowy, jako rozwiązanie, trochę takie obejście problemu, to unikanie dat na roadmapie. Czyli unikanie takiego wzorca, że roadmapa to jest jakiś rodzaj harmonogramu. Jakieś ujęcie kalendarzowe tydzień po tygodniu, miesiąc po miesiącu, kwartał po kwartale. Jeszcze daleko w przód, bardzo precyzyjne punkty w czasie, które zostają, które są jakąś taką obietnicą. Którą też bardzo trudno będzie wyjaśnić, jeśli ktoś nas będzie trzymał za słowo, że tak właśnie musi być. Taką konkretną alternatywą, to albo roa

Musisz podjąć ważną decyzję dotyczącą reorganizacji zespołów. Nie bardzo wiesz, jak się do tego zabrać.  Z tego odcinka dowiesz się, z jakich wzorców możesz skorzystać, by zmiany zostały dobrze wprowadzone. Omówiliśmy ich sześć. Każdy z przypadków opatrzyliśmy naszymi komentarzami. Będziesz wiedzieć, jakie są plusy i minusy danego rozwiązania. Musimy zaznaczyć, że nie każdy wzorzec sprawdzi się w każdym przypadku Porządny Agile · #057 – Jak zreorganizować zespoły Spis treści Jak konstruować zespoły?Manager/managerowie samodzielnie wybierają skład zespołówManagerowie opracowują wstępny szkic, a następnie opiniują go z ludźmiManagerowie zbierają pomysły, a na ich podstawie opracowują podział zadańManager określa constrainty, zespół samodzielnie dobiera się w grupy, a następnie manager zatwierdza📄Transkrypcja podcastu „Jak zreorganizować zespoły?” Jak konstruować zespoły? Podczas naszej ostatniej pracy z Klientem, kiedy napotkaliśmy wyzwanie związane z realizacją nowej strategii organizacyjnej, padło pytanie, jak przeprowadzić reorganizację zespołów? Jakie podejście warto zastosować w takim procesie? Jakie strategie i wzorce mogą pomóc w stworzeniu nowej wersji zespołów? Interpretujemy kilka momentów, w których temat reorganizacji zespołów może być kluczowy. Przykładem jest sytuacja, gdy duży zespół musi podzielić się na mniejsze zespoły lub podzespoły. Może to być również sytuacja, gdy powstaje zupełnie nowy zespół lub nowe zespoły. Inny przykład to duża zmiana w organizacji, np. reorganizacja, w wyniku której chcemy przekonstruować strukturę zespołów w odpowiedzi na nowe wyzwania. Może też być taka sytuacja, że sami jesteśmy częścią zespołu, który potrzebuje zmiany struktury. Widzimy, że w naszej części organizacji konieczne są zmiany i chcemy proaktywnie wyjść z propozycją, nie tylko stwierdzając, że zmiana jest potrzebna, ale także proponując nowy sposób podziału. Jako Scrum Master lub lider zespołu możemy zaproponować sposób, w jaki powinniśmy zbudować nową strukturę i układ zespołów. Chcemy przedstawić różne opcje, jak to zrobić. Ważne jest jednak, aby przed rozpoczęciem zauważyć, że nie każdy model, który przedstawimy, będzie kompatybilny z twoją organizacją. Dodatkowo sposób, w jaki przeprowadzimy reorganizację, może mieć wpływ na dalszy rozwój i funkcjonowanie zespołu. Wyselekcjonowaliśmy kilka wzorców, które pokazują, jak można przeprowadzić reorganizację. Wszystkie te wzorce opracowaliśmy na podstawie naszych doświadczeń z przeszłości, zarówno w zespołach, jak i firmach, w których pracowaliśmy, czy to bezpośrednio, czy jako doradcy. Poukładaliśmy je według pewnej osi – od klasycznych, intuicyjnych modeli, w których to management decyduje i komunikuje zmianę, aż po bardziej autonomiczne podejścia. Manager/managerowie samodzielnie wybierają skład zespołów Plusy: Pierwszą zaletą tego rozwiązania jest jego szybkość. W małej grupie osób (czasem nawet jedna osoba) podejmuje decyzję, opracowuje rozwiązanie i wdraża je. Cały proces jest bardzo sprawny, nie wymaga dyskusji ani zmian. W zasadzie, można powiedzieć, że „po jednej nocy” zespoły mogą zostać przekonstruowane, a po obudzeniu się wszyscy funkcjonują w nowej rzeczywistości.  Drugim plusem jest to, że taka zmiana nie generuje przesadnego zamieszania. Oczywiście, sama zmiana może wywołać pewne zamieszanie, ale nie angażuje wielu osób do analizowania sytuacji, nie ma szerokiej dyskusji. Wystarczy, że menedżerowie wymyślą nową strukturę, a potem komunikują to pracownikom. To sprawia, że proces jest efektywny, nie ma opóźnień wynikających z konieczności podejmowania decyzji przez dużą liczbę osób. Trzeci plus dotyczy sytuacji, w której menedżerowie chcą pokazać, że można działać w inny sposób. Może to być szczególnie sensowne, gdy organizacja dotychczas funkcjonowała w sposób kompetencyjny, a menedżer postanawia wprowadzić zmiany, na przykład tworząc zespoły cross-funkcyjne. W skład zespołu będą wchodziły osoby o różnych kompetencjach. W takim przypadku, gdyby proces reorganizacji wymagał konsultacji, mogłoby to napotkać opór, ponieważ każdy dział miałby swoje argumenty, dlaczego obecna struktura jest najlepsza. Dzięki tej metodzie menedżer może wprowadzić zmiany, które w normalnych okolicznościach byłyby trudniejsze do osiągnięcia. W tym scenariuszu, jeśli traktować to jako plus, to zdecydowanie dużo pracy będzie po stronie komunikacyjnej. Taka radykalna zmiana, bardziej rewolucyjna niż to, do czego firma mogłaby dojść oddolnie, musi zostać dobrze sprzedana. Musi być bardzo klarownie zakomunikowana, aby wszyscy zrozumieli, dlaczego ta zmiana zachodzi i dlaczego dokładnie w ten sposób, a nie inaczej. W przypadku większej reorganizacji szczególnie ważne jest, aby podkreślić, dlaczego ta zmiana jest konieczna. Minusy: Przechodząc do minusów, czy raczej zagrożeń takiego wzorca na zmienianie organizacji, widzimy poważne ryzyko, że zwłaszcza w większych strukturach osoby projektujące zmianę mogą nie mieć pełnego wglądu

W poprzednim odcinku rozmawialiśmy o tym, skąd brać Product Ownerów. Pozostajemy w obszarze produktowym i rozmawiamy o pułapkach odpowiedzialności Product Ownera. W tym odcinku poznasz pięć pułapek, które dokładnie analizujemy. Do każdej pułapki dajemy Ci kilka porad, które pomagają radzić sobie z nimi. Całość jak zawsze na bazie naszej praktyki. Porządny Agile · #056 – Pułapki odpowiedzialności Product Ownera W tym artykule poruszymy temat pułapek związanych z pełnieniem roli Product Ownera. Jest to kontynuacja poprzedniego tematu, w którym omawialiśmy, skąd brać Product Ownerów. Omówimy konkretne i praktyczne rozwiązania, które można zastosować w celu uniknięcia tych problemów. Spis treści Product Owner nie jest decyzyjny ( nie ma uprawnień)Product Owner, nie potrafi decydować (ma uprawnienia, ale nie decyduje) Odległości Product Ownera od KlientaProduct Owner nie ma czasu  Product Owner nie zna Scruma📄Transkrypcja podcastu „Pułapki odpowiedzialności Product Ownera” Z tego artykułu dowiesz się, jakie są najczęstsze wyzwania, z którymi borykają się Product Ownerzy oraz co zrobić, gdy Product Owner nie ma uprawnień do podejmowania decyzji czy jest zbyt daleko od swojego klienta. Product Owner nie jest decyzyjny ( nie ma uprawnień) Kiedy myślimy o roli Product Ownera, jedną z pierwszych rzeczy, która nam przychodzi do głowy, jest oczekiwanie, że będzie on w stanie podejmować decyzje dotyczące rozwoju produktu. Brak tej decyzyjności oznacza, że Product Owner nie otrzymał uprawnień ani umocowania od organizacji do podejmowania takich decyzji. 1. Ustalenie granic odpowiedzialności Product Ownera  Jest to niestety bardzo popularna pułapka. Żeby temu zaradzić, zarówno z pozycji Product Ownera, jak i z perspektywy Scrum Mastera czy Agile Coacha, pierwszym krokiem jest uzgodnienie z zarządzającymi w organizacji wizji roli Product Ownera. Może to być rozmowa z Dyrektorem Produktu, członkiem zarządu odpowiedzialnym za rozwój produktów, czy inną osobą zarządzającą obszarem, w którym działa Product Owner.  Kluczowe jest ustalenie wspólnego zrozumienia roli Product Ownera.  Problem z brakiem decyzyjności może wynikać z niezgodnych wyobrażeń co do tej roli. My, reprezentując podejście scrumowe, możemy myśleć o Product Ownerze jako osobie decyzyjnej, podczas gdy management może mieć inne wyobrażenie – widzieć go jako nowy rodzaj Project Managera, analityka, pośrednika. Ważne jest wyjaśnienie tych różnic i uzgodnienie, czym naprawdę jest rola Product Ownera w organizacji. 2. Zdefiniuj produkt i jego cel Kolejną naszą rekomendacją jest dobre zdefiniowanie produktu. W jaki sposób?  Określ co jest produktem oraz co wchodzi w jego skład. Zdefiniuj ramy, czyli bazowe informacje i kontekst potrzebny do jasnego określenia produktu, oraz bardzo konkretnie ustal cel produktu. Należy dać Product Ownerowi wycinek organizacji, za który odpowiada i w którym ma decyzyjność. To powinno wyjaśnić, jakie decyzje Product Owner może podejmować, a które należą do innych Product Ownerów lub są poza ich zakresem. Takie zdefiniowanie obszaru, na którym Product Owner ma decyzyjność, jest kluczowe, aby uzyskał pełne uprawnienia do podejmowania decyzji. Często spotykamy się z niezrozumieniem roli Product Ownera jako osoby realizującej projekty, a nie opiekującej się produktem. Jest to postrzeganie roli jako realizowanie zleconych inicjatyw z portfela projektów, zamiast rozwoju i opieki nad pewnym obszarem produktowym. Jeśli management rozumie rolę Product Ownera jako kogoś, kto ma dowieźć projekt zgodnie z wytycznymi, mamy problem z decyzyjnością. 3. Popraw umocowanie z wyższym managementem Mamy tu na myśli sytuację, gdzie Product Owner jest odpowiedzialny za produkt i jest akceptowany jako kluczowy element procesu scrumowego, ale jego ramy decyzyjności są ograniczone. Na przykład, może nie mieć swobody decydowania, musi uzyskać zgodę, drugi podpis, czy regularne korekty. W organizacjach przechodzących transformację i budujących świadomość zwinnego rozwoju produktu, umocowanie Product Ownera może być takie, jakie było wcześniej – zawsze trzeba było uzyskać zgodę. Warto przedyskutować z wyższym managementem, czy te ograniczenia są naprawdę potrzebne i jakie są ich konsekwencje. Może warto przenieść decyzyjność na nowy poziom, rozliczając Product Ownera za osiągnięte rezultaty, a nie za realizację konkretnych funkcji zgodnie z wyobrażeniem dyrektora. 4. Zmień Product Ownera  Jest to dość kontrowersyjna porada, jednak pozwól, że ją rozwiniemy. Może się zdarzyć, że mimo spełnienia wszystkich powyższych punktów, konkretna osoba w tej roli się nie odnajduje. Patrzymy na to w ten sposób – tak jak nie chcielibyśmy, aby firmą zarządzała osoba, która nie radzi sobie z tym stanowiskiem, tak samo ważne jest, aby Product Owner był odpowiedzialny i kompetentny w swoim obszarze. Spotkaliśmy na swojej drodze osoby, które w roli Product Ownera nie błyszczały, mimo wsparcia, ram i zmian, jakie wprowadzono. Z

Pytanie „skąd brać Product Ownerów” nieustannie powtarza się w naszej codziennej pracy z klientami. W tym materiale poznasz najczęstsze wzorce poszukiwania Product Ownerów oraz kilka wskazówek, na co zwrócić szczególną uwagę, by dobrze wytypować osobę do pełnienia odpowiedzialności Właściciela Produktu. Porządny Agile · #055 – Skąd brać Product Ownerów? Spis treści W jakich miejscach poszukiwać osób do roli Product Ownera?Porady dla osób, która szukają Product OwnerówMateriały dodatkowe📄Transkrypcja podcastu „Skąd brać Product Ownerów?” W jakich miejscach poszukiwać osób do roli Product Ownera? Rozważamy poniżej funkcje, role albo miejsca, z których warto szukać kandydatów do pełnienia odpowiedzialności Właściciela Produktu. Product Manager  Jednym z możliwych kandydatów na rolę Product Ownera może być osoba obecnie pełniąca funkcję Product Managera. W organizacjach, gdzie struktura produktowa jest już częściowo ukształtowana lub funkcje zarządzania produktem istnieją w obszarze biznesowym, osoba pełniąca tę funkcję może być naturalnym wyborem na stanowisko Właściciela Produktu. W realiach firmy pracującej w Scrumie przejęcie odpowiedzialności scrumowej przez Product Managera często pozwala na skuteczne połączenie zarządzania produktem z wymaganiami frameworka. Czy Product Manager ma „pod sobą” Product Ownera odpowiedzialnego za dostarczanie? Taki model działania jest często spotykany w organizacjach. A może odwrotnie, to Product Owner zarządza produktem, a w jego otoczeniu funkcjonują Product Managerowie dostarczający wsad do podejmowania decyzji? Albo może właściwym podejściem jest traktowanie Product Ownera jako odpowiedzialności przypisanej do osoby pełniącej funkcję Product Managera w organizacji (i obie odpowiedzialności skupione są w jednej osobie)? Spotykamy w organizacjach wszystkie te warianty i uważamy, że takie decyzje strukturalne są zależne od kontekstu danej firmy – nie mamy tu jednej zawsze sprawdzającej się rekomendacji. „Właściwa” osoba z biznesu z prawem do decydowania Kolejny często spotykany wzorzec to wybór Product Ownera bezpośrednio z obszaru biznesowego. Oznacza to, że rola trafia do osób mających realny wpływ na decyzje dotyczące dostarczanych produktów lub usług. Tym, co odróżnia to podejście od wcześniej opisanego, jest brak przywiązania do konkretnych etykiet stanowisk. Niezależnie od tego, jaką funkcję pełni obecnie kandydat czy jest specjalistą w danej dziedzinie, strategicznym Project Managerem czy kierownikiem nie kierujemy się etykietami, lecz analizujemy, kto obecnie posiada najlepsze kompetencje, wiedzę i pozycję, by przejąć odpowiedzialność za produkt. Oprócz kompetencji i wiedzy warto również uwzględnić poziom zaufania, jakim dana osoba cieszy się w organizacji. Istotne jest to, czy kandydat ma wystarczający autorytet, by przejąć odpowiedzialność Product Ownerską. Mowa o odpowiedzialności rozumianej jako realna decyzyjność i rozliczalność za rezultaty i wyniki, a nie formalna rola podporządkowana zewnętrznemu sterowaniu czy ścisłemu nadzorowi. Wzorzec polegający na poszukiwaniu odpowiedniej osoby wśród przedstawicieli „biznesu” sprawdza się zwłaszcza w organizacjach, które nie mają jeszcze ugruntowanej struktury produktowej lub w których zespoły powstają w sposób wymykający się obowiązującym schematom. Analityk biznesowy albo systemowy Przy braku wsparcia i współpracy ze strony „biznesowej” może się okazać, że spośród wszystkich dostępnych kandydatur to właśnie analityk będzie najbardziej oczywistym wyborem. Warto jednak dobrze się zastanowić, czy dana osoba jest gotowa przyjąć odpowiedzialność za produktowe myślenie. Wielu analityków (biznesowych lub systemowych) funkcjonuje dziś w paradygmacie realizacji projektu lub rozwoju systemu. Tymczasem perspektywa „buduję produkt, zarządzam produktem” to sposób myślenia właściwy Product Ownerowi i procentujący w dłuższej perspektywie. Dotychczasowi analitycy rzadko uwzględniają ten aspekt lub nie przywiązują do niego większej wagi. Umiejętność analitycznego myślenia i cała dziedzina wiedzy z tego obszaru to elementy, które realnie wspierają pracę Product Ownera, szczególnie w zakresie porządkowania i strukturyzowania Backlogu Produktu. Kompetencje analityczne ułatwiają również formułowanie trafnych pytań. To uniwersalny fundament, który może wspierać osobę pełniącą rolę Product Ownera. Warto jednak pamiętać, że część tych kompetencji może zostać celowo rozwinięta w zespole i stopniowo przekazywana Developerom. Niezbędne będzie również zdobycie wiedzy dotyczącej pozycjonowania produktu. Zrozumienie konkurencji czy ustalanie cen to kolejne obszary, które mogą stać się elementem odpowiedzialności. To szereg decyzji czysto produktowych, które dla analityka pracującego dotąd bez kontekstu produktowego, wykonującego analizy na potrzeby różnych interesariuszy, może oznaczać konieczność uzupełnienia wiedzy i dostosowania się do nowego kontekstu.  Osoba z doświadcze

Czym jest Water Scrum Fall? Ten popularny w wielu organizacjach antywzorzec wszczepia elementy zwinności w klasyczny, kaskadowy proces wytwarzania produktów. W odcinku tłumaczymy zagrożenia związane z tym antywzorcem, jak zawsze na bazie praktycznych przykładów z naszego doświadczenia. Dowiesz się, jak poradzić sobie z Water Scrum Fall’em, zarówno z poziomu zespół, jak i osób zarządzających organizacją.  Porządny Agile · #054 – Water Scrum Fall Zobacz wersję wideo Dodatkowe materiały Scrum Studio 📄 Transkrypcja podcastu „Water Scrum Fall” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Jacek: W dzisiejszym odcinku opowiemy czym jest Water Scrum Fall i dlaczego ten antywzorzec jest pewną pułapką? Opowiemy na początku czym jest Water Scrum Fall? Dlaczego uważamy, że jest niebezpiecznym antywzorcem? A następnie podzielimy się swoim praktycznym doświadczeniem, jak radzić sobie z Water Scrum Fallem, zarówno w pojedynczym zespole oraz jak zmienić organizację systemowo, żeby wyjść z tej pułapki. Kuba: Water Scrum Fall jest tutaj pewnym hasłem, czy nazwą wzorca, który zbiera pewną grupę rozwiązań organizacyjnych. Rozwiązań, w których w procesie wytwarzania produktu, czy wytwarzania oprogramowania, czy przygotowywania jakichś produktów szerzej rozumianych, stosowane są techniki zwinne, ale są one wyłącznie środkową częścią kaskadowego procesu. Czyli jakiegoś takiego procesu bardzo przypominającego rozwiązania klasyczne związane z zarządzaniem portfelem, na przykład inicjatyw projektowych, gdzie jest jakiś etap inicjowania, wymyślania, selekcjonowania, priorytetyzowania, być może projektowania, wyceniania i te wszystkie etapy przed rozpoczęciem wytwarzania. Samo wytwarzanie może nawet jest na przykład z użyciem Scruma. Istnieje zespół zwinny, który iteracyjnie i przyrostowo przygotowuje zleconą inicjatywę. Potem być może jest jeszcze etap po wytworzeniu. Czyli jakieś przygotowanie wdrożenia, może jakieś osobne testy przed wdrożeniowe. Szereg czynności, które dzieją się zgodnie z istniejącymi procedurami. Są dalekie od tego, co kojarzy się ze stylem współpracy w sposób zwinny. Termin ten, czyli Water Scrum Fall, rozpowszechniła firma Forester. Firma badawcza, która w swoim raporcie stwierdziła w którymś momencie, że jest to popularny wzorzec stosowania podejścia zwinnego, czy takiego zaadaptowania filozofii zwinnej w firmach na całym świecie. Jacek: Kilka pułapek, na które chcielibyśmy zwrócić uwagę. Przede wszystkim można powiedzieć, że cementuje pewien determinizm, w którym na bardzo wczesnym etapie trwania inicjatyw projektów, czy ogólnie rzeczy, którymi się zajmujemy, na bardzo wczesnym etapie podejmujemy pewne decyzje. I to często wynika z takiego podejścia, że czujemy, co trzeba zrobić. To jest dokładnie to, co powoduje, że szereg rzeczy usztywnia się na samym początku pracy z konkretną inicjatywą. Na bazie tych z czasem starzejących się założeń, a czasem wręcz można powiedzieć nieaktualnych, wykonujemy pracę – można powiedzieć, z rozpędu. No co powoduje, że już na etapie wytwarzania operujemy na niewłaściwych danych. Kuba: Kolejna pułapka, też wynikająca z takiego podejścia – ktoś decyduje na dosyć wczesnym etapie. To jest pułapka tego, że oddzielamy tych, którzy wymyślają. Tych, którzy decydują. Tych, którzy myślą strategicznie, którzy posiadają informację i swobodę decyzji, od tych, którzy już potem są tylko wykonawcami. A może nawet nazwalibyśmy ich podwykonawcami, czyli brak kontekstu, oderwanie od tych przyczyn, nieświadomość, jakie istniały inne opcje, które zostały w ramach tego wzorca Water Scrum Fall sprowadzone do zróbcie dokładnie to. Jak to wykonacie, to będzie wszystko w porządku. Jacek: Kolejna pułapka, to dosyć długi czas wynikający z rozbudowanego procesu. W takim sensie, że od momentu pojawienia się pomysłu, do momentu, kiedy ten konkretny pomysł jest zrealizowany, upływa masa czasu i wcale to nie wynika z tego, że jest dużo pracy do zrobienia, tylko z tego, że ten cały proces jest dosyć taki obudowany i biurokratyczny. Kuba: I tutaj mamy bardzo prosty przykład z pewnej organizacji, w której funkcjonowałem przez parę lat w swojej przeszłości, gdzie w którymś momencie w ramach refleksji na temat procesu projektowego, jaki funkcjonował w tej organizacji, policzyliśmy czas, który zająłby projekt o zerowej zawartości. Taka powiedzmy hipotetyczna zabawa. Projekt nie ma w sobie nic do wykonania. Nie ma żadnej pracy, żadnych testów, żadnej analizy. Tylko po prostu przepuszczamy przez nasz system taki projekt zerowy. No i projekt zerowy trwałby kilka miesięcy, bo trzeba czekać kilka tygodni na decyzję komitetu zatwierdzającego inicjatywę. Trzeba czekać w kolejce po tak zwane zasoby. Trzeba czekać w kolejkach na jakieś okienka. Trzeba czekać, aż ktoś wykona testy. On sobie gwarantuje w procedurze minimalny czas na to. Procedura wdrożeniowa również gwarantuje minimalne czasy. W wielu takich wzorcach okazuje się, że zwinność fajnie w śro

Poznaj czym jest timeboxing. Dowiesz się, z jakich rodzajów timeboxów możesz skorzystać, by Twoja praca była łatwiejsza i uporządkowana. Dzielimy się z Tobą kilkoma wskazówkami, które przetestowaliśmy i dobrze sprawdzają nam się w codziennej pracy. Dzięki temu łatwiej zapanujesz nad harmonogramem swoich zadań oraz będziesz wiedzieć, ile one zajęły Ci czasu. Porządny Agile · #053 – Timeboxing Zobacz wersję wideo Sprawdź nasz webinar o dzieleniu elementów Backlogu Produktu na mniejsze elementy. Dodatkowe materiały Technika Pomodoro 📄 Transkrypcja podcastu „Timeboxing” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Kuba: Ten odcinek poświęcimy timeboxingowi. Specjalnie zostaliśmy przy angielskiej nazwie na tę praktykę. Chociaż znamy polskie tłumaczenie, ograniczenie czasowe, które podpowiada, chociażby polskie tłumaczenie Przewodnika po Scrumie, to mimo wszystko mamy poczucie, że w takim codziennym obrocie, nie jest ono zbyt często używane, więc zostaniemy przy tym angielskim, lekko odmienianym, ale jak oryginalnym. Widzimy, że takie podejście po prostu jest stosowane w praktyce w zespołach. Nie chcemy tutaj wprowadzać jakiegoś zamieszania. O czym konkretnie będzie ten odcinek? Zdefiniujemy na początek czym jest timeboxing. Potem wspomnimy, na jakiej bazie modeli i prawideł funkcjonuje to podejście. Dlaczego to się to stosuje w praktyce? Pokażemy kilka przykładowych poziomów zastosowania timeboxingu. Całość odcinka skwitujemy kilkoma podpowiedziami, czy wskazówkami praktycznymi, które powodują, że ten timeboxing jest stosowany lepiej w wybranych zespołach, czy firmach. Jacek: Co to jest timebox? Timebox, to jest z góry określony odcinek czasu, podczas którego konkretna osoba, bądź konkretny zespół działa, wykonuje jakieś czynności, żeby osiągnąć z góry ustalony cel. Za całą ideą Timeboxingu stoi kilka praw, czy pewnych takich zjawisk, które chcielibyśmy wyszczególnić. Pierwsze prawo, z którym myślę, że wiele osób spotkało się w praktyce, to Prawo Parkinsona. Polega ono na tym, że praca wypełnia, czy może ma tendencje do tego, żeby wypełniać cały dostępny czas, jaki na tę pracę przewidzimy. Czyli przykładowo, jeżeli zaplanuję sobie, że do końca tygodnia będę zajmował się jakimś konkretnym projektem, czy zadaniem, no to zwykle w praktyce wygląda to tak, że te działania nasze rozkładają się, rozszerzają się, że gotowi jesteśmy faktycznie na koniec tego czasu, który sobie zaplanowaliśmy. Kuba: I tutaj dobrze zastosowany Timeboxing wykorzystuje to prawo, ale tak dla dobra obu stron. Czyli zakładamy sobie pewne odcinki czasowe, najlepiej krótkie, a nie odwrotne podejście, które czasami intuicyjnie niektórzy chcą zastosować, czyli zajmie to zadanie, czy zajmie mi ten projekt tyle czasu, ile czuję, że potrzebuję. Bo niestety, ale zgodnie z Prawem Parkinsona, jak powiesz, że potrzebujesz trzy miesiące, to zajmie Ci to trzy miesiące. Kolejne prawo, czy może syndrom, jak to się nazywa, które też stoi za zastosowaniem timeboxa, to „syndrom studenta”. Gdy wykonujemy jakieś działania, zaczynamy taką faktyczną pracę, albo przyspieszenie pracy, albo takie poważne wzięcie się w garść, dopiero chwilę przed końcem terminu, dopierodopiero gdy już czujemy, że ten zegar tyka i że ten termin się zbliża. No i tu znów, jeśli stosujemy timeboxy, zwłaszcza relatywnie krótkie, no to mamy ten deadline, czy ten „syndrom studenta” nam się uruchamia dosyć szybko po rozpoczęciu Timeboxa. Jacek: Tu mogę tylko potwierdzić z praktyki, że faktycznie syndrom studenta działa. Natomiast jeszcze kolejnymi zjawiskami, które warto odnotować, jest nieumiejętność oceny czasu. Generalnie mamy problem z tym, żeby poprawnie oszacować ile coś nam zajmie czasu. Zwykle jest to składowa wielu czynników. No i oczywiście im bardziej złożone zadanie, im próbujemy uchwycić dłuższy odcinek czasu, no tym to nasze oszacowanie może być bardziej przestrzelone. Kuba: Nieumiejętność oceny czasu ma też miejsce w przypadku pracy w krótszych odcinkach czasowych. Jest takie bardzo proste ćwiczenie, które się kiedyś mi sprawdziło na szkoleniu. Proszę wszystkich uczestników, żeby podnieśli rękę w momencie, gdy upłynie minuta. Od momentu, gdy powiem start. Nie mogą zaglądać w zegarek. Nie mogą widzieć żadnego sekundnika, tylko mają na wyczucie powiedzieć, kiedy ich zdaniem ta minuta upłynie. To jest ciekawe ćwiczenie, które zachęcam do odtworzenia. Gdybyś nie dowierzał, nie dowierzała, że to tak działa, prawdopodobnie w dużej grupie, zwłaszcza takiej też różnorodnej, może się okazać, że pierwsze ręce podniosą się w okolicy dwudziestej sekundy, a może trafi się też bardzo wytrwały, który dwie minuty poczeka. I to jest proste ćwiczenie, ale ono pokazuje to, że po prostu to poczucie upływającego czasu to jest coś bardzo względnego. Bardzo czułego na to, jak bardzo jesteśmy zaangażowani, jak bardzo nas kręci, to co robimy. Jak bardzo jesteśmy rozproszeni. Ile mamy energii, albo jak bardzo jesteśmy wyczerpan

Jakie zachowania intuicyjne kojarzą się z obniżaniem ryzyka w agile, a jak to wygląda w praktyce? W odcinku rozmawiamy o pułapkach intuicji i podpowiadamy konkretne wskazówki, skupiając się na praktycznym, a nie książkowym podejściu do zarządzania ryzykiem. Każdą pułapkę próbujemy zrozumieć, ocenić kryjące się za nią niebezpieczeństwo oraz proponujemy sprawdzone sposoby radzenia sobie w takich sytuacjach. Porządny Agile · #052 – Obniżanie ryzyka w agile Zobacz wersję wideo 📄Transkrypcja podcastu „Obniżanie ryzyka w agile” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Jacek: Jakiś czas temu facylitowałem spotkanie z Klientem, podczas którego rozmawialiśmy o pułapkach intuicji. Czyli zaczęliśmy rozważać, które rzeczy myślimy, że działają, a które rzeczy działają naprawdę. Ta myśl, którą obrobiliśmy wspólnie na warsztatach, stała się dla nas pomysłem dla nas na dzisiejszy odcinek. Kuba: Jest to interesujący wątek i rzadziej poruszany w takim tutaj środowisku tworzonych treści wokół zwinności. Niedawno też mieliśmy takie pytanie od jednej z naszych słuchaczek, którą teraz pozdrawiamy, która pytała właśnie, jakie paradoksy wiążą się z agilem. Na temat tego odcinka wybieramy wątek obniżania ryzyka w agile. Więc porozmawiamy o tym, jakie zachowania intuicyjnie mogą się kojarzyć z tym, co obniża ryzyko. No i niestety, to będą rzeczy, które mogą być mocną pułapką, więc zaproponujemy swoje kontrpropozycje sprzeczne z taką prostą intuicję, ale faktycznie obniżające ryzyko w agile. Co bardzo istotne, poruszymy te wątki praktycznie. Czyli nie chcemy tutaj w ogóle wchodzić w wątek książkowej definicji ryzyka, zarządzania ryzyka, klasyfikację ryzyka. Po prostu, od razu przejdziemy do wątku, jak to w praktyce widzimy, że się realizuje w zespołach zwinnych. Książki, parę za moimi plecami widać, na filmie na YouTube, można sobie zobaczyć. Warto czytać, natomiast my się skupimy tutaj stricte na praktyce. Jacek: No dobrze Kuba, to gdybyś miał podać pierwszy przykład. Co podpowiada nam intuicja, a co z kolei naszym zdaniem, faktycznie pomaga obniżyć ryzyko w pracy zwinnej? Kuba: Te intuicje wprowadzimy w postaci cytatów. Więc ja tutaj tak spróbuję się wczuć w osobę, która ze mną dyskutuje. No i czasami słyszę taki głos. „Jak dobrze przeanalizujemy wszystko na początku, to niczego nie pominiemy”. Potrafię zrozumieć osobę, która używa takiego argumentu. Powołuje się ona na chęć niepominięcia niczego, takiego dogłębnego przeanalizowania, zastanowienia się. Sprawdzenia wszystkich możliwych tutaj założeń. I jeśli zrobimy to porządnie, jeśli zrobimy to dobrze, jeśli zrobimy to na początku projektu, no to już wszystko pójdzie prosto. Tylko niestety z tą prostą intuicją, z którą do jakiegoś stopnia empatyzuję, jest spore założenie, czy spory problem. Mamy tutaj taki problem, czy pułapkę myślenia deterministycznego, że faktycznie wystarczy naprawdę dobrze pomyśleć, wystarczy naprawdę dobrze popytać, poszukać, sprawdzać. No i będziemy mieli opanowany cały zakres. Będziemy mieli to wszystko prawdopodobnie również spisane, zaplanowane, porozkładane na części pierwsze. Ja się bardzo obawiam, że takie założenie daje złudne poczucie panowania nad zakresem, które jest niestety tylko złudzeniem. Jacek: No i to co byśmy chcieli tutaj zaproponować w zamian, to zamiast takiej próby uchwycenia wszystkiego perfekcyjnie od samego początku, raczej rekomendowalibyśmy takie iteracyjne odkrywanie produktu. Czyli taką symultaniczną czynność w stosunku do samego procesu wytwarzania, w której, zanim podejmiemy się realizacji jakiegoś konkretnego zadania, zdobywamy dowody z rynku od naszych Użytkowników, od naszych Interesariuszy, że te pomysły faktycznie mają sens. To jest jakby jedna rzecz. Z drugiej strony, że nasz pomysł na ich implementację również jest właściwy. Kuba: I, żebyśmy się dobrze zrozumieli. Broń Boże nie sugerujemy, że należy natychmiast rzucić się do pracy. Nie zastanowić się na początku co robimy, jaki jest tego cel, dla kogo to robimy? Natomiast, no tutaj sugerujemy po prostu to, żeby wykonać jakieś czynności związane z odkrywaniem produktu od początku, ale być po pierwsze OK, z tym że nie uda się wszystkiego przewidzieć, wszystkiego przemyśleć, wszystkiego zebrać. I co ważne, nawet jeśli mamy wrażenie, że już w miarę czujemy, o co chodzi, to nie zgubić tego momentu. Że być może na początku byliśmy w błędzie. Być może się myliliśmy? Albo zmieniły się realia, na przykład rynkowe, albo konkurenci coś wprowadzili, albo Klienci zaczęli trochę inne rzeczy preferować. Stąd mocne założenie, robimy odkrywanie produktu na początku prac, ale nie porzucamy tej koncepcji odkrywania produktu również w trakcie dalszego wytwarzania kolejnych wersji, kolejnych przyrostów. Wracamy do tych koncepcji. Być może tylko po to, żeby się utwierdzić, że wszystko jest w porządku. Dobrze to przemyśleliśmy, ale mimo wszystko tutaj czai się ryzyko, o którym jest ten odcinek. Czai się ryzyko, że źle zint

18 listopada 2020 roku twórcy Scruma podczas webinaru przedstawili najnowszą aktualizację w Przewodniku po Scrumie. W tym odcinku dzielimy się z Tobą na gorąco naszymi przemyśleniami na temat najważniejszych zmian. Odcinek nie pokrywa wszystkich modyfikacji, których jest ich dużo więcej, niż się spodziewaliśmy. Z odcinka dowiesz się, co szczególnie zwróciło naszą uwagę. Mamy też kilka wątpliwości, m.in. jakie faktyczne znaczenie dla zespołów zwinnych będą miały te zmiany? Sprawdź nasze pierwsze refleksje po aktualizacji i koniecznie samodzielnie zapoznaj się z aktualizacją Przewodnika po Scrumie. Porządny Agile · #051 – Aktualizacja Przewodnika po Scrumie 2020 Zobacz wersję wideo 📄 Transkrypcja podcastu „Aktualizacja Przewodnika po Scrumie 2020” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Jacek: Dzisiejszy odcinek, taki spontaniczny dosyć, poświęcimy, żeby skomentować z Kubą na gorąco aktualizację Przewodnika po Scrumie, która dzisiaj, 18. listopada została upubliczniona przez twórców Scruma. Jesteśmy świeżo po webinarze. Odpoczęliśmy trochę. Podyskutowaliśmy z Kubą o naszych przemyśleniach na gorąco i chcielibyśmy się tymi przemyśleniami z Tobą podzielić. Kuba: Na pewno jest tak, że podkreślę również ja, odcinek będzie trochę bardziej spontaniczny, niż taki, do którego już przyzwyczajony lub przyzwyczajona. Sam też odcinek nie pokryje absolutnie wszystkich zmian, jakie w tym Scrum Guidzie nastąpiły. Jest ich nawet trochę więcej, niż się spodziewaliśmy. Stąd struktura odcinka będzie raczej skupiona wokół tego, że zaczniemy od punktów, które zwróciły naszą szczególną uwagę i wymienimy się listą pewnych przemyśleń i pewnych komentarzy na ten temat. No i w drugiej części odcinka, pod koniec odcinka, podzielimy się też kilkoma wątpliwościami, na takim trochę meta poziomie. Czyli mniej związane z tym, że Scrum się konkretnie zmienia w takich, a nie innych zdaniach, ale też, jakie to ma znaczenie dla zespołów zwinnych, dla ruchu zwinnego, czy dla społeczności praktyków zwinności. To zacznijmy może od tych przemyśleń. Same te przemyślenia też chcieliśmy w jakąś taką w miarę uporządkowaną listę zebrać. Co mamy na pierwszym miejscu Jacek? Jacek: Na pierwszym miejscu mamy takie przemyślenie, właściwie obserwację, co do której się oboje zgodziliśmy, że co do zasady ten bardzo szeroko rozumiany kierunek zmian, jeśli chodzi o najnowsze wydanie przewodnika po Scrumie, no jest dobrym kierunkiem. Sporo konkretnych zmian, które zostały zaproponowane, to co do zasady są dobre zmiany. Również rzeczą, która zwróciła naszą uwagę i też pozytywne jest to, że ten cały dokument został skrócony. Więc nie mamy, zdaje się osiemnastu stron, tylko trzynaście. Natomiast czytając tak w pierwszym, czy drugim czytaniu, osobiście odnoszę wrażenie, że strony zostały zredukowane, natomiast nie czuję, żeby to miało negatywny impakt na wydźwięk tego, co pozostało jako treść. Kuba: No i tu, jak Jacek mówi zgadzamy się. Ja sam czuję, że uproszczenie to jest dobry kierunek. Natomiast tutaj, to uproszczenie nie spowodowało jakiegoś pogorszenia, jakichś pominięć, czy dziwnych niezrozumień. W wielu miejscach nawet mamy do czynienia z przypadkiem, że nie dość, że pewien akapit, który w poprzedniej wersji przewodnika po Scrumie był dosyć rozbudowany, teraz jest sprowadzony raptem do kilku zdań. To jeszcze w dodatku te kilka zdań, jest o wiele bardziej konkretnych, niż pierwotne, czy poprzednie brzmienie tych myśli. Więc ogólny kierunek zmian w przewodniku po Scrumie, no zgadzamy się z tym, jak to jest reklamowane i sami byśmy to też tak określili. Uproszczona treść, mniej preskryptywna, jeśli to jest również, to jest polskie słowo, taka prosta kalka z angielskiego. No i co ważne też, fajnie, że jednocześnie przy tej  mniejszej ilości treści, większa jednoznaczność tego, jak to jest poukładane i zakomunikowane, czym Scrum jest i co to znaczy dobrze realizować, czy dobrze wykorzystywać metodę scrumową. Jacek: Moim zdaniem jest to też sensowny kierunek, z tego względu, że nadal co do zasady i to nie uległo zmianie, Scrum pozostaje frameworkiem, czyli ramami postępowania. Z mojej perspektywy, im więcej rzeczy było przemycanych do przewodnika, tym większa była pokusa, że dokładnie tak właśnie trzeba robić. Tu słynny przykład z trzema pytaniami z Codziennego Scruma. On bardzo mocno sugerował, że właśnie tak to należy robić, czy taki też bardzo precyzyjny opis, jak powinien wyglądać Przegląd Sprintu. Tak więc, jeżeli to ma być framework, jeżeli to ma być lekkie, jeżeli to ma zmuszać nas do myślenia, no to odchudzanie, to jest zdecydowanie dobry kierunek. Kuba: Kierunek, z którym się zgadzamy z Jackiem, że ten nowy Przewodnik wytycza, taka koncepcja podniesienia poprzeczki. W kilku miejscach mamy takie odczucie, czy tak sobie te zmiany interpretujemy, że o wiele bardziej na serio Scrum wytycza jakieś podpowiedzi, jak powinna być realizowana praca zespołu. Jak powinien być umiejscowiony w organizacji?

Sytuacja na świecie przeniosła nas do świata online. Dzięki współczesnej technice możemy ciągle pracować nad naszymi projektami. Odcinek jest kontynuacją tematu poprzedniej rozmowy o facylitacji spotkań, ale tym razem mówimy o praktyce dotyczącej uczestnictwa w spotkaniach online. Mamy dla Ciebie garść  naszych porad, jak dobrze prowadzić i w nich uczestniczyć. Dowiesz się, co się tutaj najlepiej sprawdza. Jak zawsze nasze doświadczenie i rady są wynikiem bardzo dużej ilości spotkań przeprowadzonych w taki sposób z wieloma zespołami. To nasz 50. odcinek. Dziękujemy, że nas słuchasz. Nagrywamy dla Ciebie już od ponad dwóch lat. P.S Nie zapomnij włączyć kamery na spotkaniu! Porządny Agile · #050 – Spotkania online Zobacz wersję wideo Dodatkowe materiały Porządna Retrospektywa Sprintu 📄 Transkrypcja podcastu „Spotkania online” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Kuba: Możesz zauważyć, że dzisiaj intro było wyjątkowo odmienne, ponieważ jest to nasz 50. odcinek. Musimy się przyznać, że rok temu nie zauważyliśmy, że minął nam rok nagrywania. Teraz dwa lata z lekkim okładem. Bardziej okrągła liczba 50. odcinek, więc zanim zaczniemy samą treść nagrania, to parę słów od nas na temat tego, że nagrywamy od ponad dwóch lat. Bardzo się cieszę, że realizujemy ten produkt. Bardzo się cieszę, że możemy robić te nagrania dla Ciebie. Ja przyznam, że nagrywanie – co mnie kompletnie zaskoczyło – bardzo porządkuje mi wiedzę i cieszę się, że kolejne materiały, kolejne audycje są przygotowywane. Realizujemy je z Jackiem na temat tego, co wiemy. Porządkujemy sobie wiedzę i sami się niejednokrotnie zaskakujemy, jak dużo treści możemy Wam przekazać. Bardzo cieszymy się, jak dostajemy informację zwrotną na temat tego, jaką wartość mają dla Was te odcinki. Każdy z nas ma „Impostor syndrome”. Ja też go mam. Cieszę się, że takie nagrania wychodzą naprzeciw temu i dostają docenienie, czy dostaję pozytywny feedback. Jacek: Ja chyba najbardziej obawiałem się, jak zaczynaliśmy, że nie uda nam się utrzymać regularności. Udało się nagrać 50 odcinków. Udało się, to tak zabrzmiało, jakby to był przypadek, a to generalnie nie jest przypadek. Raczej bym powiedział pewna konsekwencja. Tak jak sobie myślałem dzisiaj, to życzyłbym nam wszystkim, i Tobie Słuchaczu i nam, żebyśmy spotkali się przy setnym odcinku. Bardziej okrągłej rocznicy. Myślę, że to jest wykonalne. Natomiast taka moja druga obawa była taka, że może zabraknie nam tematów. Po 50. odcinkach wiem, że tematów nie zabraknie. Kuba: Tematów jest jeszcze więcej, niż do tej pory, niż do tej pory nagranych odcinków, więc to spokojnie może być realizowane, jeśli chodzi o merytorykę. A co dzisiaj? W tym odcinku chcielibyśmy kontynuować wątek, który pierwotnie przewidywaliśmy w odcinku 49, który prawdopodobnie jest już za Tobą, był o podstawach facylitacji spotkań, czy prowadzenia spotkań, przygotowywania spotkań. Gdy przygotowałem się do tego tematu z Jackiem, pierwotnie myśleliśmy z Jackiem, żeby nagrać o spotkaniach online. No i ten poprzedni odcinek był wstępem. Był takim fundamentem, bazą o wszystkich możliwych spotkaniach, a odcinek 50. będzie rozszerzeniem tego wątku, ale dedykowanym tylko i wyłącznie do spotkań online. Dzisiaj opowiemy trochę naszych porad, trochę naszych przemyśleń na temat tego, co się sprawdza w spotkaniach online. Jak je zrobić dobrze? O jakich punktach warto pamiętać? Wymienimy te porady w pewnej kolejności i trochę o nich też opowiemy szerzej. Jak zwykle są to rzeczy, które po prostu nam się sprawdzają w praktyce, które obserwujemy w pracy z zespołami, z którymi mamy obecnie kontakt. Więc też jest tak, nawet jeśli tego wprost nie mówimy, to są nasze przemyślenia. Nasza wiedza, czy jakaś praktyka. I przechodząc bardzo konkretnie do porad, jest jedna porada, która nam przychodzi, jeśli chodzi o spotkania online, jako absolutna podstawa, coś, od czego zaczynamy, bez czego nie możemy przeżyć spotkań online. No jest to porada, włącz kamerę. Nasze spotkania nie zawsze są na video. Nie zawsze są z udziałem wszystkich uczestników i wtedy bardzo mocno cierpimy, czy bardzo mocno widać tę niedoskonałość, gdy opieramy się tylko i wyłącznie na połączeniu głosowym. No to takie poczucie, jakbyśmy w latach 90. mieli połączenie telefoniczne. Gdzieś tam coś skrzypi, coś słyszy. Nie wiadomo, czy po drugiej stronie jest w ogóle człowiek, czy właśnie od tego komputera odszedł. Nie widzimy swojej mowy ciała. Nie widzimy, czy ta osoba ma naszą uwagę, nie reaguje na to, jak przebiega dane spotkanie. No i nie widzimy tej całej miękkiej strony, czy tej ulotnej kwestii komunikacji. Właśnie z gestykulacją, z reakcjami, z jakimiś nastrojami. Wszystkie te rzeczy, które powodują, że komunikacja jest o wiele głębsza i o wiele dokładniejsza, niż tylko bazowanie na słowach. Jacek: Sporo osób w czasie pandemii narzeka na to, że kontakt, który zwykle miały w biurze z innymi osobami, że z nim jest kłopot. Jed

Przeprowadzanie efektywnych spotkań może wydawać się proste. Ustalamy godzinę i spotykamy się w wyznaczonym czasie. Wystarczy omówić występujące problemy, postęp prac nad projektem, ustalić co, kto robi, a potem rozejść się do przydzielonych zadań. Okazuje się jednak, że w trakcie rozmowy z zespołem, mogą pojawić się różne problemy, które wymieniamy w tym odcinku. Dowiesz się na co należy uważać. Mamy też dla Ciebie sprawdzone przez nas porady, które pozwolą Ci uniknąć pułapek, które omówiliśmy. Porządny Agile · #049 – Facylitacja spotkań Zobacz wersję wideo Dodatkowe materiały Kluczowe protokoły Państwa McCarthy Poręczne opracowanie – Facylitacja spotkań 📄 Transkrypcja podcastu „Facylitacja spotkań” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Jacek: W dzisiejszym odcinku poruszamy z Kubą temat facylitacji spotkań. Jest to temat, z którym spotykamy się na co dzień, pracując z Klientami i dostrzegamy, że, pomimo iż może wydawać się, że jest to temat prosty, można powiedzieć oczywisty. Bo co to za problem zrobić spotkanie. No a rzeczywistość pokazuje nam, że no nie zawsze to wygląda tak kolorowo. Pomimo iż poruszymy naszym zdaniem absolutne podstawy, no to widzimy przestrzeń na rynku, żeby takie podstawy zaczęły funkcjonować w zespołach. Kuba: Jest spora szansa, że to nagranie będzie bardziej uniwersalne. Nie dotyczyć będzie tylko i wyłącznie spotkań zespołów zwinnych. Więc jeśli słuchasz tego podcastu dzięki temu, że ktoś polecił Tobie ten odcinek, to pamiętaj, że notatki do tego odcinka z linkami do materiałów, które wspominamy w trakcie nagrania, transkrypcją, zapisem video całego nagrania, znajdziesz to wszystko na stronie porzadnyagile/49. Jacek: Odcinek rozpoczniemy od przedstawienia, jakie najczęstsze problemy można zaobserwować w trakcie spotkań. Nie będzie to jakiś długi wywód. Nie będziemy za bardzo z Kubą głęboko wchodzić w te problemy, o których mówimy. Myślę, że są na tyle jasne i na tyle popularne, że wystarczy, że je po prostu tutaj delikatnie zasygnalizuję. Pierwszy taki klasyczny problem, z którym się spotykamy, jeśli chodzi o organizację spotkań, jest problem polegający na tym, że bardzo często spotkania się odbywają, jednak nie mają żadnego moderatora. Czyli nie ma nikogo, kto by odpowiadał, żeby konkretne spotkanie zostało przeprowadzone w efektywny i skuteczny sposób. Kuba: Następna niepokojąca sytuacja, to taka niedoskonałość dyskusji, którą ja nazywam „rozmowa w powietrzu”. Czyli dużo rozmów, ale polegających wyłącznie na warstwie słownej. Wyobrażamy sobie, co druga strona w dyskusji ma na myśli, ale kompletnie tego nie widzimy i wielokrotnie z tego powodu się mocno nie dogadujemy. Jacek: Innym popularnym problemem jest chaotyczna dyskusja. Chaotyczna rozmowa, czyli takie spotkanie, gdzie tak naprawdę trudno powiedzieć, czy za tym całym spotkaniem stoi jakaś konkretna myśl, jakiś konkretny pomysł. Ktoś coś mówi, ktoś inny się odzywa. Właściwie całe spotkanie przegadujemy. Jednak to niekoniecznie prowadzi do jakichś konkretów. Kuba: Następnym problemem to to, że mamy poczucie zmarnowania czasu. Dyskusja się toczy. Zatacza może drugie, trzecie okrążenie. Nie ma z tego żadnych rezultatów. Nie podejmujemy żadnej decyzji. Nie wyciągamy żadnych wniosków. Mamy poczucie kompletnego marnowania czasu. Jacek: Innym popularnym problemem jest dominacja w dyskusji przez konkretne osoby, co powoduje, że jednej osoby jest bardzo dużo. Jej głos, jego głos jest bardzo silny w trakcie spotkania, co jednocześnie powoduje taki problem, że są też osoby, które albo mają bardzo mało wkładu w konkretne spotkanie, albo co też nie wyjątkiem potrafią się nie odezwać, bądź nie wziąć udziału w dyskusji w ogóle. Kuba: Niektóre spotkania mogą sprawiać wrażenie pospiesznej rozmowy. Takiej rozmowy w stylu kłócących się polityków. Kolejne osoby się przekrzykują. Nie ma czasu się zastanowić. Każda wypowiedź musi być wtrąceniem w wypowiedź innej osoby. Wszyscy mają poczucie takiego pędu, biegnięcia. Może to nie prowadzić do celu, zwłaszcza gdy ta rozmowa ma być bardziej głęboka, czy bardziej kreatywna. Jacek: Innym problemem jest brak decyzyjności w trakcie tych spotkań. Czyli rozmawiamy, rozmawiamy, dyskutujemy, wymyślamy. Potem rozważamy opcje. Natomiast tak naprawdę nie zapadają żadne decyzje. Tak jak weszliśmy bez konkretów, bez ustaleń w spotkanie, tak samo z tego spotkania bez jakichkolwiek ustaleń wychodzimy. Kuba: Niektóre spotkania też bardzo cierpią na tym, że wchodzimy na nie, dyskutujemy, dyskutujemy i po dyskusji rozchodzą się jakieś strony tej dyskusji. Każdy ze swoimi wnioskami. Każdy myśli, że wygrał negocjację. Każdy myśli, że udało się przekonać tę drugą stronę do swojego zdania. Jacek: Ostatnia rzecz, którą obserwujemy, nazwaliśmy to „Dzień świstaka”, czyli właściwie każde spotkanie wygląda tak samo, jak spotkanie w dniu poprzednim. Podobny styl prowadzenia. Podobnie często nieefektywne i tak naprawdę mamy wrażenie, że

Nie istnieje jeden konkretny, najlepszy model zarządzania Scrum Masterami. Jest ich kilka, mają swoje zalety i wady, ale nie o tym jest ten odcinek. Nie zdradzimy, który model preferujemy. Mamy dla Ciebie listę konkretnych pytań, które możesz potraktować jako inspirację do myślenia i działania. Wybrany model zarządzania może się również zmieniać, w zależności od tego, na jakim etapie jest organizacja. Pamiętaj, że to co sprawdza się w jednej firmie, nie musi oznaczać, że zadziała u Ciebie. Porządny Agile · #048 – Zarządzanie Scrum Masterami Zobacz wersję wideo 📄 Transkrypcja podcastu „Zarządzanie Scrum Masterami” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Kuba: Ten odcinek poświęcimy tematowi zarządzania Scrum Masterami. Jest to szeroki wątek i spróbujemy go zarysować, zdefiniować, a później rzucić kilka inspiracji, kilka pytań, kilka może nawet prowokacji. Jest to temat, który jest różnorodnie rozwiązywany w różnych firmach. Nie mamy tutaj ambicji dać jednej, jedynej słusznej wersji. Raczej zarysujemy znane nam możliwe formy, możliwe sposoby funkcjonowania Scrum Masterów – zarówno jako struktura, czy rozwiązania strukturalne w ramach firmy, ale też pewien proces pracy Scrum Masterów. Ich umiejscowienie, ugruntowanie tej roli w firmie. Tak rozumiemy zarządzanie, tak rozumiemy też to zarządzanie Scrum Masterami. I tutaj zaczniemy właśnie od definicji. Jacek: Chcieliśmy na początku narysować jakie różne formy może przybierać pojęcie, które rozumiemy jako zarządzanie grupą Scrum Masterów. Pierwszy taki sposób, który obserwujemy, to nazwaliśmy to sobie Scrum Master Office. Skrót SMO. Mamy tutaj na myśli taką bardzo formalną strukturę. Często to jest struktura, która powstaje na fundamencie istniejącej struktury biura projektów, PMO – czyli Project Management Office. Charakteryzuje się tym, że jest to taka struktura, w której Scrum Masterzy bardzo mocno odpowiadają za proces, ale też często ta odpowiedzialność nosi taką bardziej formułę papierowo-raportową. Wszystko jest pięknie poukładane, wszystko jest wyraźne, dostępne, zaraportowane, w kolorach – czerwonych, żółtych, zielonych. Natomiast jakby ciemna strona takiego sposobu funkcjonowania zwykle polega na tym, że zwykle jest to skupienie nieco zbyt mocno na tej formule procesowej. No i gdzieś w tym wszystkim często obserwujemy, że gubi się to takie pierwotne zrozumienie zwinności. Kuba: Taki Scrum Master Office, to jest najbardziej wyrazisty sposób na zarządzanie Scrum Masterami, bo mówimy tutaj o dedykowanej jednostce organizacyjnej, która na pewno ma swojego przełożonego. Być może jest to osoba najbardziej zaawansowana w Scrum Masteringu. Może to jest osoba, która też współodpowiada za transformację całej firmy? Na pewno są tam jakieś formy rozwoju kariery, rozwoju kompetencji. Na pewno są jakieś ścieżki wymiany wiedzy. Wszystkie zalety jakiegoś takiego centrum kompetencyjnego, czy po prostu jednostki organizacyjnej, która całkowicie poświęcona jest zawodowemu i profesjonalnemu realizowaniu roli Scrum Mastera. Ale nie przypadkowo, jak się zastanowiliśmy, jak na przyszłą część odcinka nazwać, no to trochę z przekąsem – to Scrum Master Office, żeby to właśnie nawiązanie do starego, dobrego PMO tutaj się pojawiło. Drugi rodzaj sposobu funkcjonowania Scrum Masterów w firmie, to jest coś, co nazwaliśmy Gildią Scrum Masterów. Mamy tu na myśli taki przypadek, w którym Scrum Masterzy, to są osoby pełniące tę rolę zawodowo, ale są oni gdzieś po organizacji rozłożeni. To nie jest scentralizowana jednostka. Wśród tych Scrum Masterów jest wskazana jakaś osoba, jakiś ekspert, jakiś Agile Coach, może któryś ze starszych Scrum Masterów.Może po prostu jeden z liderów. Jakiś może bardziej doświadczony Scrum Master, który jest wskazany, jako osoba, która ma zaanimować działanie takiej grupy Scrum Masterów. Są to zawodowcy, nie są scentralizowani, ale są w jakiś sposób zaanimowani, więc się prawdopodobnie spotykają. Prawdopodobnie w jakiś taki sposób skoordynowany ze sobą współpracują, również pomiędzy zespołami, a nie tylko każdy w swoim zespole. Jacek: Kolejna konstrukcja, to konstrukcja, w której Scrum Master to jest funkcja. Czyli Scrum Masterzy są w zespołach. Nie można nie mieć Scrum Mastera. Organizacja umówiła się na kierunek, w którym każdy zespół, który używa Scruma, ma Scrum Mastera. Natomiast ci Scrum Masterzy są wpięci pod różnych managerów, pod różnych kierowników. Nie ma w takiej sytuacji jednej osoby, która miałaby jakąś wizję na rozwój tej grupy. Nie ma jednej osoby, która odpowiada za wszystkich SM’ów, za ich rozwój. Tylko po prostu Ci Scrum Masterzy są. Robią swoją robotę. Natomiast każdy z nich raportuje po jakiejś tam linii raportowania, która w organizacji funkcjonuje. Tak więc wielu Scrum Masterów może raportować do wielu managerów, do wielu kierowników. Kuba: Następną metodą zarządzania Scrum Masterami, ona już zaczyna być taka dyskusyjna, czy to jeszcze jest zarządz

Scrum Guide nie definiuje wprost pojęcia Definition of Ready. Jest to jednak rozszerzenie, które bywa stosowane na różne sposoby w wielu zespołach. Dowiesz się, dlaczego ta praktyka może być potrzebna w zespole i jak ją stosować. Damy Ci kilka przestróg oraz rad jak zacząć, a także czego należy unikać przy zastosowaniu Definition of Ready. Temat został zaproponowany przez jednego z naszych Słuchaczy w ankiecie dotyczącej podcastu. Porządny Agile · #047 – Definition of Ready Zobacz wersję wideo 📄Transkrypcja podcastu „Definition of Ready” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Kuba: Przed tobą czterdziesty siódmy odcinek podcastu Porządny Agile, w którym poruszymy temat Definition of Ready. Jeden z naszych słuchaczy w ankiecie, którą robiliśmy jakiś czas temu, poprosił o to, żebyśmy właśnie poruszyli ten temat. W ramach odcinka zdefiniujemy, co rozumiemy pod Definition of Ready, co w sumie nie jest takie banalne, bo Scrum Guide tego bezpośrednio nie definiuje. Powiemy, dlaczego taka praktyka może być potrzebna w zespole, opowiemy też jak zacząć stosować Definition of Ready i na koniec opowiemy o paru przestrogach, kilka rad jak się do tego zabrać, ale też czego według naszych doświadczeń unikać przy zastosowaniu Definition of Ready. Zacznijmy tak, jak wspomniałem już wcześniej zaczniemy od definicji, co to jest Definition of Ready Jacek? Jacek: Sama definicja Definition of Ready generalnie ma swoje źródło w okolicach Scruma. Pierwszy raz została użyta tak w sposób formalny około 2008 roku. Natomiast przez ten czas była wykorzystywana w tym frameworku, no i myślę, że w ten właśnie sposób zdobyła popularność. W największym skrócie jest to pewna umowa wewnątrz zespołu, która definiuje nam, po czym poznajemy, że konkretne elementy w naszym Backlogu Produktu wyglądają na gotowe do pobrania, gotowe do zaplanowania podczas planowania Sprintu. Kuba: I tak metodologicznie bardzo mocno trzeba podkreślić, że Definition of Ready, a zwłaszcza tak rozumiane twardo jako ten trzyliterowy zbitek, nie występuje w Przewodniku po Scrumie, to jest raczej praktyka towarzysząca, która Scruma rozszerza. No i w szczególności mocno to podkreślmy, praktyka formułowania i przestrzegania Definition of Ready nie jest w Scrumie obowiązkowa. Ona jest dobrą praktyką. Praktyką, która warto zastosować, no ale w samym Scrum Guide, czyli tym takim wytycznej, co jest Scrumem, a co jest tylko okolicą Scruma. W tym Scrumie mówimy raczej o gotowości Backlogu Produktu, czy stanie gotowości, stanie gotowości tych poszczególnych elementów tego Backlogu Produktu, ale można to osiągnąć na różne sposoby. Do tego wątku jeszcze trochę wrócimy w przestrogach pod koniec odcinka. Jacek: No dobrze, a gdybyś miał powiedzieć, dlaczego tak naprawdę taka, czy takie Definition of Ready, trzymając się angielskiej nazwy, do czego to nam jest potrzebne? Kuba: Jest kilka powodów i taka najbardziej oczywista. Oczywiste tłumaczenia, oczywisty sens tego, żeby Definition of Ready funkcjonowało, to jest próba uniknięcia przez zespół brania na Sprint rzeczy z Backlogu Produktów, które są jakiś sposób. No przede wszystkim mi się wydaje niedogadane. Czyli rozpoczynamy pracę, być może nawet ją jakoś próbujemy planować. Grzecznie sobie jako zespół współpracujemy. No i  w zasadzie prawie natychmiast po rozpoczęciu pracy, już w środku Sprintu odkrywamy, że rzeczy są nieprecyzyjnie sformułowane. Nieprzemyślane, sprzeczne ze sobą i pewnie jeszcze kilka innych przypadków może się natrafić. Co nam rozwala kompletnie plan pracy, co nam rozwala możliwość realizacji celu Sprintu. Być może również gdzieś stawia pod znakiem zapytania sensowność realizowania jakichś sąsiednich tematów, bo to, co robimy, jest częścią czegoś większego. No to wszystko powoduje, że zespół nie realizuje Celu Sprintu. Ma bardzo niski procent skuteczności realizacji planowanych elementów Backlogu wziętych na Sprint. No i raczej mówimy tu o przypadku, gdzie jest chaos, gdzie jest jakieś może nawet już grupa wzajemnych pretensji, jakichś takich niedopowiedzeń. W każdym razie zespół, który zawodzi sam siebie, no i zawodzi też swoje otoczenie, ponieważ no nie może polegać na tym, co przewiduje, że zrobi w czasie planowania Sprintu Jacek: Definition of Ready może być też pomocne, gdy zależy nam na pamiętaniu o tym, żeby nie pominąć jakichś zależności zewnętrznych. Mam tu na myśli sytuacje, w których pewne kompetencje, bądź nawet pewne zmiany, które zespół chciałby wyprodukować, nie są stuprocentowo zależne od zespołu, tylko leżą, bądź w innych zespołach, bądź w innych działach, bądź w ogóle poza organizacją, której te zespoły funkcjonują. Przykładem takich zależności zewnętrznych, to może być np. pamiętanie o tym, żeby skonsultować jakąś zmianę prawnie. To tu to jest przykład na taką zależność, zarówno potencjalnie wewnętrzną, jeżeli mamy dział prawny wewnątrz organizacji, ale równie dobrze może to być kompletnie zewnętrzna organizacja, z którą po prostu

Przedstawiamy Ci różne układy pełnienia roli Project Managera w zespole Scrumowym. Sprawdź, w którym z nich jesteś. Temat jest rozwinięciem pytania, które zadał nam nasz Słuchacz na facebookowym live. W rozmowie nawiązujemy też do naszych zawodowych doświadczeń w tej funkcji. Wskazujemy na plusy i minusy omawianych konfiguracji. O tym posłuchasz w 46. odcinku podcastu Porządny Agile. Porządny Agile · #046 – Project Manager w Scrumie Zobacz wersję wideo Dodatkowe materiały Zwinne projekty i produkty Praca na termin w Agile Scrum bez Project Managera? Rola PM w transformacji Agile Rola Scrum Mastera i Project Managera – przewodnik po obowiązkach i stylach pracy PM i Scrum Master – dwie różne gry, które nie warto mierzyć jedną miarą Zobacz making of z tego nagrania 📄 Transkrypcja podcastu Project Manager w Scrumie Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Jacek: W dzisiejszym odcinku nawiązujemy do pytania, które pojawiło się podczas naszego ostatniego live’a na Facebooku. Mamy poczucie, że to pytanie nie zostało dostatecznie, głęboko przez nas poruszone. Pytanie dotyczyło bardzo szeroko rozumianej roli Project Managera w Scrumie. Chcielibyśmy dzisiaj trochę bardziej systemowo podejść do tego tematu i opowiedzieć Tobie, jak podchodzimy do tematu tej konkretnej roli, w tym konkretnym frameworku. Kuba: Odcinek poukładaliśmy w poszczególne zadania związane z możliwymi układami pełnienia roli Project Managera w zespole Scrumowym. Dla Twojej wygody podam spis treści tego, co będziemy w kolejnych częściach nagrania wspominać. Zaczniemy od sytuacji, gdy PM jest nad całym zespołem wytwórczym, nad całym zespołem Scrumowym. Później przejdziemy do sytuacji, gdy PM jest ustawiony w organizacji na równi z Product Ownerem i Scrum Masterem. Wspomnimy też o sytuacji, gdy PM istnieje w zespole Scrumowym, ale niestety nie ma ról Product Ownera lub Scrum Mastera, lub są one bardzo niewyraźne. Znamy też przypadki, gdy PM jest w środku zespołu wytwórczego i to też trochę to poeksplorujemy. Skończymy z sytuacją bardzo wyrazistą, gdy PM-a w ogóle nie ma w całym układzie zespołu Scrumowego. Zespół Scrumowy nie posiada, ani w sobie, ani dookoła siebie Project Managera. Cały odcinek skończymy z refleksją związaną z tym, jak działać w zwinności, gdy jest się w roli Project Managera. To jest zwłaszcza ukłon z tych z Was, którzy tutaj są zachęceni do pracy zwinnej w jakiś sposób, a w swojej organizacji obecnie pełnią rolę Project Managera Jacek: Pierwszy przypadek, który chcielibyśmy omówić, to jest przypadek, kiedy Project Manager, określiliśmy to sobie, jest nad wszystkimi innymi rolami. Jest to taki case, kiedy zespół pracuje używając Scruma. Mamy rolę Product Ownera, Scrum Mastera, mamy rolę zespołu developerskiego i nad tym wszystkim, można powiedzieć, taką pewną warstwą jest właśnie Project Manager, który stanowi pewnego rodzaju taki „single point of contact” tej całej grupy, właściwie zespołu Scrumowego z resztą organizacji. W naszej ocenie jest to model, nazwaliśmy to sobie – suboptymalny, czyli taki model, który z naszej perspektywy nie jest najbardziej optymalną formą wykorzystania tego zwinnego frameworka do wytwarzania produktów, usług czy czegokolwiek czym konkretnie zajmuje się zespół developerski. Kuba: Największy problem, jaki mamy w taką sytuacją, to przede wszystkim – z góry skazanie się na pośrednictwo, czy zjawisko takiego głuchego telefonu. Głuchego telefonu, nie tylko jeśli chodzi o obieg informacji, ale też swego rodzaju pośrednictwu czy outsourcingu, jeśli chodzi o odpowiedzialności. Product Owner jest decydentem, jeśli chodzi o priorytety rozwoju produktu, ale do wyższych warstw zarządzania, jego albo wytyczne, albo informacje, albo jakieś nowe konteksty, przechodzą przez jeszcze kolejną osobę, która nad tym wszystkim trzyma pieczę, albo zbyt bardzo wyraziste komunikaty wygładza, albo filtruje, albo nawet nieświadomie trochę przeinacza. Jakby się nie wysilać, no komunikacyjnie jest to kłopot i potencjalnie również odpowiedzialnościowo, ktoś tutaj może być odcięty od pełnej informacji, od pełnej odpowiedzialności takiego zobowiązania się do tego, co jest realizowane. No i niestety takie układanki, gdzie PM jest powyżej całego zespołu Scrumowego mogą czymś takim grozić, mogą coś takiego wprowadzać. Jacek: Z mojej perspektywy chyba najbardziej taką negatywną stroną tej konfiguracji jest to, że najczęściej w takim ustawieniu ten nasz Product Owner, on pełni rolę taką absolutnie podwykonawczą. Czyli mówimy tutaj o modelu, w którym to Project Manager wyznacza priorytety, nadaje kierunek prac, a Product Owner jest zwykle sprowadzony do takiego zarządcy Backlogu, albo jak to niektórzy mówią – Product Owner odpowiada za delivery, czyli właściwie tylko za to, żeby na czas w określonej jakości dostarczać jakieś konkretne rozwiązania. Z mojej perspektywy, w sensie mam jakby problem z taką konfiguracją na wielu płaszczyznach, zarówno

Jesteś liderem lub managerem i odczuwasz strach przed utratą kontroli w podejściu zwinnym? W tym odcinku omawiamy ten konkretny case i pokazujemy na bazie konkretnych pytań, jak dyskutować, analizować i podchodzić systemowo do takiego tematu. Rozmowa może być też inspiracją dla wyższego managementu czy liderów transformacji, pokazując jakie zagadnienia warto brać pod uwagę w kontekście zwinnych transformacji. To wszystko posłuchasz w 45. odcinku podcastu Porządny Agile. Porządny Agile · #045 – Jak wspierać managerów w procesie zmiany? Zobacz wersję wideo Dodatkowe materiały Koszty podejścia zwinnego 📄Transkrypcja podcastu „Jak wspierać managerów w procesie zmiany?” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Jacek: W dzisiejszym odcinku poruszymy temat, który został zgłoszony do nas przez jednego z naszych słuchaczy bądź słuchaczek w ankiecie. Zostaliśmy poproszeni Kubą, żebyśmy poruszyli temat o wspieraniu liderów i managerów tak, aby nie bali się utraty kontroli. Kuba: Zaczęliśmy dyskusję na temat tego odcinka i zastanawialiśmy się, jakbyśmy do tego tematu podeszli, bo to jest w zasadzie w pytaniu lepienie dwóch wątków, więc z jednej strony wspieranie liderów z drugiej strony całe zagadnienie o tym jak to agile nie jest utratą kontroli. Ostatecznie podjęliśmy z Jackiem decyzję, że pokażemy Tobie, jak byśmy pracowali z takim case’em. Czyli literalnie, dosłownie powiemy jak byśmy wspierali liderów tak, aby nie bali się utraty kontroli, ale to nie jest ani odcinek o wspieraniu liderów, ani to nie jest bezpośrednio odcinek o utracie kontroli przez agile, tylko raczej pokazanie takiego case’a, pokazanie na przykładzie jak można w ogóle dyskutować, rozważać, zabierać się do takiego tematu. Myślę, że te dyskusje, które ze sobą tutaj stoczymy oraz pokażemy tak trochę na przykładzie jak pracujemy z trudniejszymi sytuacjami. Mogą być ciekawą inspiracją zarówno z perspektywy Scrum Mastera czy Agile Coacha, który mierzy się z takim zagadnieniem w swojej firmie, czy wokół swojego zespołu. Ale też liczymy na to, że to będzie również inspiracja dla wyższego managementu, agentów zmiany, liderów transformacji, żeby zobaczyć, jakie zagadnienia warto rozważyć, warto na mnie spojrzeć. Spojrzeć głębiej, spojrzeć szerzej. I cały sens tego odcinka, to będzie trochę dyskusji na temat listy pytań, które byśmy zadali w tej sytuacji, właśnie wspierania liderów  przed tą obawą utraty kontroli. Jakie jest pierwsze pytanie, do którego doszliśmy, przygotowując się do odcinka. Jacek: Pierwsze pytanie brzmi. Czy manager dobrze rozumie sens zmiany? I z drugiej strony, patrząc tak bardziej w stronę organizacji czy sen zmiany został dobrze wytłumaczony? Będziemy się trzymać generalnie tego wzorca. Zawsze spojrzymy najpierw z perspektywy osoby, później zawsze spojrzymy z perspektywy organizacji. Zaczęliśmy od takiego naszym zdaniem, bardzo istotnego punktu widzenia, gdzie sięgamy absolutnie do początku, do pewnego rodzaju źródła zmiany. Czyli do odpowiedzi na pytanie, dlaczego w ogóle chcemy się zmieniać? Co stoi za potrzebą zmiany? Czego się spodziewamy? O jakich rezultatach mówimy? Jak jest wizja firmy po zmianie? Tutaj staramy się spojrzeć na temat zarówno z tej perspektywy czy manager rozumie sens, czy ta cała zmiana została dobrze wytłumaczona, zakomunikowana. Jakiej jakości była to komunikacja? Ale jednocześnie chcemy spojrzeć na to z perspektywy organizacji. Czyli zadać sobie pytanie, czy zostały wykonane wszystkie możliwe kroki zapewniające, że nie będzie pytań bez odpowiedzi. Co oczywiście może być taką sytuacją trudną do osiągnięcia i zawsze ktoś nie czyta komunikacji, nie usłyszy, nie będzie w stanie sparafrazować. Natomiast no na pewno warte rozważenia jest to, czy w ogóle te takie absolutne podstawy dotyczące tego, dlaczego ten cały wysiłek wykonujemy, zostały zapewnione. Kuba: Może się to wydawać, że to pierwsze pytanie jest bardzo ni na temat, no bo przecież case, o którym mówimy, to jest manager boi się utraty kontroli i jakoś źle interpretuje podejście zwinne. Ale zaczynamy od tego punktu, czy mocno polecam zaczynać od takiego właśnie zagadnienia – Jaki jest ten głębszy sens? Jaki jest tutaj w tym przypadku temat zmiany w podejściu zwinnym? Zmiana roli managera. Jaki jest ten głębszy sens, po co to w ogóle się dzieje? Po co firma wymyśliła sobie, żeby cokolwiek zmieniać? Bo prawdopodobnie w odpowiedzi na takie pytania, jaki jest ten sens zmiany i też się jak my go dobrze tłumaczymy z perspektywy organizacji? Prawdopodobnie w odpowiedzi na ten temat jest parę ważnych zagadnień, za które można się zaczepić w dalszej rozmowie z takim managerem. Jeśli mówimy tu o rozmowie np. bezpośrednio z tym managerem, który ma jakieś obawy związane ze zmianą. Bo prawdopodobnie sens tej zmiany w zależności oczywiście od organizacji, tu będziemy trochę ogólnie, ale prawdopodobnie jest to coś, o tym jak dotychczasowe metody nie są wystarczające. O tym, jako organizac

Czy organizacja powinna mieć zwinną społeczność? Jak można ją stworzyć? Jak można ją rozwijać i animować, żeby ciągle działała? Mówimy o tym, jak wykorzystać jej istnienie i potencjał w danej organizacji. Jakie korzyści wynikają z istnienia zwinnej społeczności? Tego dowiesz się z 44. odcinka podcastu Porządny Agile. Przekazujemy Ci także kilka sprawdzonych praktyk, jak zawsze popartych naszymi doświadczeniami.  Porządny Agile · #044 – Firmowa społeczność zwinna Zobacz wersję wideo Dodatkowe materiały Techniki moderacji spotkań społeczności Bring your own problem Lean Coffee Open Space Liberating Structures 📄Transkrypcja podcastu „Firmowa społeczność zwinna” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Kuba: Ten odcinek poświęcimy tematowi zwinnych społeczności w ramach organizacji. Opowiemy o tym, jak według naszego doświadczenia takie zwinne społeczności mogą się rozwijać. Jak można je animować. Jak można je tworzyć, a potem też podtrzymywać przy życiu. Ale też poza aspektem takiej samej transformacji, czy uruchamiania takich społeczności wychodzimy z założeniem, czy z taką tezą, że cechą zwinnej organizacji są silne, istniejące i działające zwinne społeczności. Dlatego też oprócz tego aspektu zaczynania zwinnej społeczności chcemy też podpowiedzieć też trochę jak takie zwinne społeczności przytrzymać przy życiu, jak wykorzystać ich istnienie i ich potencjał w danej organizacji. Jacek: I bardzo często pytania jak tworzyć takie społeczności, czy jak wspierać takie społeczności pojawiają się w organizacjach, które wspieramy w procesie zwinnej transformacji. Czasem te społeczności już funkcjonują, czasem są dopiero w zalążku, a czasem dopiero wykształca się pomysł, czy pojawia się pomysł na to, że być może to jest ten moment, kiedy powinniśmy się zastanowić nad wsparciem uruchomienia takiej społeczności. Jakbyś miał Kuba zdefiniować, czy przekonać naszego Słuchacza, dlaczego warto taką społeczność uruchomić, to co Ci przychodzi do głowy? Kuba: Przede wszystkim nasuwa mi się taki temat – możliwości wymiany myśli. Mamy w takiej społeczności osoby z różnej perspektywy i jest szansa, że osoby wzajemnie się będą gdzieś tutaj wzmacniać, dawać sobie różne kąty patrzenia na daną sytuację. Jacek: Myślę sobie, że te kąty patrzenia mogą być albo pewnego rodzaju wymianą myśli, ale mogą też przybrać taką formę już konkretnego wsparcia, czyli mamy jakiś problem, mamy jakąś zagwozdkę. Pojawię się na społeczności i to jest miejsce, w którym mogę czerpać od innych osób. W efekcie po prostu wyjść z jakąś wiedzą, która pozwoli mi lepiej wykonywać mi moje codzienne obowiązki. Kuba: Jak mówisz o czerpaniu, to też automatycznie następny wątek się nasuwa sam. To takie inspirowanie się. Ja mam swój punkt widzenia, mam swoje kąty, ale mam też swoje ograniczenia postrzegania. Ktoś z boku mi coś da do myślenia, może coś przeczytał. Może coś wysłuchał. Może w ogóle widzi ten problem zupełnie inaczej i bo jakoś zreformułował. Więc takie zwinne społeczności wzajemnie dla siebie mogą też być okazją do inspiracji. Inspiracji do rozwiązywania problemów. Inspiracji do przesuwania sobie tej zwinności w swoim zespole w jakieś inne miejsce. Jacek: Jak tak słucham tego, co mówimy, to w sumie taka do głowy przychodzi mi  taka klamra, że de facto można też powiedzieć, że taka społeczność może nam pomóc w rozwoju. Bardzo szerokim tego słowa rozumieniu, bo to może być i taki rozwój – mnie, jako moja wiedza, która jest mi potrzebna do codziennego działania, ale też taki rozwój, w sensie, być może te relacje, które tam z osobami nawiąże, też będą (nazwijmy to) rozwojowe w kontekście szerszego patrzenia na organizację. Kuba: Wspomniałeś relacje. One same w sobie też mogą być wartością zwinnych społeczności. Czyli możemy zbudować pewną integrację między zespołową. Zwłaszcza jeśli mówimy tu o społeczności zwinnej, w skład której wchodzić mogą: Scrum Masterzy, Product Ownerzy, być może jacyś pasjonaci podejścia zwinnego. No to prawdopodobnie oni będą przychodzić z bardzo różnych zespołów. Być może na co dzień rzadziej ze sobą pracujących. Jeśli wejdą w skład społeczności, będą aktywnie działać, jest spora szansa, że się po prostu ze sobą zintegrują. Będą się znać z imienia, będą umieć ze sobą współpracować w przyszłości. Jacek: W sumie od tego, co mówisz to jest tylko już krok do tego, żeby taka społeczność już mogła, oprócz tego, że będą się znać i być może tą znajomość przełożą na płynniejszą, lepszą, szerszą współpracę w życiu codziennym. No to też będą mogli dojść do takiego punktu, w którym będą mogli wspólnie wypracowywać rozwiązania, które będą do zastosowania nie tylko w konkretnym zespole, w którym ja się znajduję, ale szeroko dla całej organizacji. Kuba: Te rozwiązania to może być też już konkretnie wyjście naprzeciw jakimś problemom organizacyjnym, tak zwanym scrumowym impedimentom. Jakieś niedoskonałości, które poszczególne osoby w społeczności, a może nawet cała społ

Czym jest utrzymanie w agile? Jakie zagrożenia mogą pojawić się kiedy nie zarządzamy utrzymaniem? Dowiesz się czego powinno się z pewnością unikać. Omawiamy też kilka dobrych praktyk dotyczących utrzymania. Sami z nich korzystamy w pracy z zespołami czy firmami nad ich zwinną transformacją. Porządny Agile · #043 – Zarządzanie utrzymaniem w agile Zobacz wersję wideo Dodatkowe materiały Kanban przy kawie – odcinek 6 📄 Transkrypcja podcastu „Zarządzanie utrzymaniem w agile” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Jacek: W dzisiejszym odcinku porozmawiamy o utrzymaniu w podejściu zwinnym. Jest to temat, który został zgłoszony przez naszych Słuchaczy w ankiecie, którą niedawno zakończyliśmy i nad tym tematem dzisiaj się pochylimy. Kuba: W ramach odcinka zdefiniujemy co rozumiemy pod utrzymaniem. Opowiemy jakie są zagrożenia niezaopiekowanego tematu utrzymania i podzielimy się z Tobą praktykami, które nam przychodzą do głowy, gdy myślimy o temacie dobrego ogarnięcia, utrzymania praktyki, z których sami korzystamy, korzystaliśmy w przeszłości i sami je propagujemy obecnie, gdy pracujemy z zespołami czy firmami nad ich transformacją zwinną. Zaczniemy od definicji. To jest o tyle istotne, że to tak pierwsza uwaga na metapoziomie, że to utrzymanie bywa rozumiane bardzo różnie w różnych firmach. Bywa też różnie rozumiane pomiędzy zespołami, a na przykład poziomem managerskim. Więc tutaj tak jak mówię – definiujemy w ramach tego odcinka. To jest coś, co nam pomaga, żebyśmy mówili na temat, ale to też jest pytanie, które warto sobie zadać w czasie pracy, czy w czasie dyskusji na temat tych procesów. Utrzymanie definiujemy jako utrzymanie produkty, rozumiane przed przykłady, błędy ze środowiska tak zwanego produkcyjnego, czyli tego, na którym już korzystają Klienci, z którego korzystają Użytkownicy. Opieka nad tym środowiskiem poprzez na przykład upgrady bibliotek, upgrady frameworków. Być może jakiś monitoring, podłączanie go, aktualizacja. Być może odczytywanie jakichś ważnych informacji z tego monitoringu. Czasem praca utrzymaniowa to są jakieś audyty. Raz na jakiś czas trzeba sprawdzić, czy wszystko działa tak, jakbyśmy chcieli. Może jakieś formalne audyt rozumiany jako przegląd kodu albo przegląd stosowanych procesów czy narzędzi. Utrzymaniem mogą też być jakieś niezbędne prace sprawiające, że produkt dalej funkcjonuje. One nie są zmianą biznesową, nie są zlecone przez biznes, a są niezbędne, żebyśmy dalej dobrze funkcjonowali. To są jakieś parametryzacje, jakieś dodatkowe małe zmiany, które powodują, że wszystko to, czym jest nasz produkt i za co cenią nas nasi Klienci – wszystko to funkcjonuje. Podsumowując – to utrzymanie jest niezbędnym elementem tego, żeby produkt funkcjonował. To może być przez negację, to jest wszystko, co nie jest zmianą biznesową, nie jest projektem, nie jest zlecone przez zamawiających różne rzeczy, czy to Product Ownera, czy też Interesariuszy. Jacek: Kilka zagrożeń, które widzimy, jeśli chodzi o zarządzanie utrzymaniem. Pierwsze jest takie, że nie zarządzanie w jakikolwiek sposób utrzymaniem powoduje problem dla zespołów, kiedy przychodzi do planowania pracy. Jest to temat, który nieustannie wraca, czy podczas prac z Klientem, czy podczas różnego rodzaju szkoleń, czy warsztatów. A jak sobie radzić z utrzymaniem, kiedy pracujemy zwinnie. Ten problem wynika z tego, że trudno oczekiwać od zespołu skupienia, czy trudno oczekiwać od zespołu efektywności, czy trudno oczekiwać od zespołu przewidywalności. Jeżeli co chwilę pojawia się jakaś praca, która nie jest zaplanowana, jest nieprzewidziana, a z różnych powodów tę pracę musimy wykonać. Tak więc, jeżeli chcemy mieć przewidywalne zespoły warto zarządzać w świadomy sposób tym wszystkim, co przed chwilą Kuba zdefiniowałeś jako utrzymanie. Kuba: Zagrożeniem niezajęcia się utrzymaniem albo traktowania go po macoszemu jest też to, że koszty wprowadzenia takich zmian mogą zacząć bardzo rosnąć. To będą albo koszty poprawiania rzeczy po dużym czasie albo koszty takie biznesowe, jeśli czymś się nie zajęliśmy. Niezaopiekowane utrzymanie może prowadzić do awarii. Może prowadzić do jakichś problemów związanych z kompromitacją systemu z perspektywy bezpieczeństwa. Szereg kosztów biznesowych, które narastają tylko dlatego i rosną do poziomu już takich krytycznych dla funkcjonowania firmy, tylko dlatego, że ktoś gdzieś kiedyś przeoczył, nie odjął na odpowiednim priorytecie jakiejś drobnej pracy czy jakiegoś drobnego zadania, które sprawia, że nie mamy luk, że wsparcie dla naszego systemu jest nadal aktualne. Te zabezpieczenia i ten poziom technologiczny jest całkowicie zaopiekowanym. Jacek: Niewątpliwie zagrożeniem jest też wzrost długu technicznego. Czyli takie konsekwentne nierealizowanie rzeczy, które są ważne. Rzeczy, które są istotne. Rzeczy, które powinniśmy zrobić. Długotrwałe utrzymywanie takiego trendu zwykle powoduje problemy i bardzo często te problemy przychodzą

Jak HR może wesprzeć zwinność w firmie? Rola HR-u może zawierać się w planowaniu transformacji, pogłębieniu zmiany kultury organizacyjnej. Czasem konieczne mogą się okazać zmiany w obszarze tzw. “twardego HR-u” oraz potrzeba reagowania na potrzeby, które pojawią się w czasie trwającej transformacji. Bazujemy na pozytywnych przykładach i historiach z naszego doświadczenia zawodowego. Porządny Agile · #042 – Rola HR w agile Zobacz wersję wideo Dodatkowe materiały: Koszty podejścia zwinnego Zwinna transformacja to niekończący się proces blog Kuby – Jak HR może wesprzeć zwinność w organizacji 📄 Transkrypcja podcastu „Rola HR w agile” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Kuba: W dzisiejszym odcinku opowiemy o tym jaka jest rola HR w agile. Cały odcinek, jeśli chodzi o konstrukcję treści bazuje na moim wpisie z bloga kubaszczepanik.pl, który jest podlinkowany w notatce do tego odcinka, ale podeszliśmy do tego nagrania na świeżo, na nowo. Wzięliśmy tylko te podstawowe punkty i spróbujemy razem z Jackiem przejść przez te najważniejsze rzeczy, które Wam chodzą po głowie, jeśli chodzi o rolę czy to HR jako działu, czy też przedstawicieli HR, szefa lub szefowej HR w przeprowadzaniu transformacji oraz wspieraniu zwinności, która już funkcjonuje w danej firmie, czy na poziomie IT, czy na poziomie całej organizacji. Jaki jest pierwszy punkt, jeśli chodzi o rolę HR w agile? Jacek: Pierwszy punkt, którym chcemy się podzielić to punkt, który mówi o planowaniu pierwszych kroków transformacji we wsparciu, w wykonaniu tych kroków. I tutaj mamy na myśli szereg działań, które pojawiają się i są konieczne do wykonania, jeśli myślimy o zwinnej transformacji. Taki pierwszy przykład, to na przykład są szkolenia. Jeżeli chcemy oczekiwać, że zespoły zaczną pracować w zwinny sposób, że managerowie zaczną lepiej wykorzystywać swoją pozycję, żeby wzmacniać podejście zwinne, no to konieczne jest przeprowadzenie szkoleń – czyli zadbanie o to, żeby ludzie mieli pewne wspólne zrozumienie pewnych pojęć, żeby wiedza się wyrównała, że jak mówimy iteracja, czy jak mówimy przyrostowość, no to, żebyśmy mówili o tych samych rzeczach. Więc chociażby taka prozaiczna rzecz, jak na przykład szkoleniach, jeżeli oczywiście mówimy o firmy, która ma kilkanaście, kilkadziesiąt a może kilkaset osób – no to już jest spore wyzwanie organizacyjne. Kuba: Z rzeczy, które też mogą podlegać planowaniu i też są potrzebne w ramach transformacji, to na pewno będzie jakaś forma akcji komunikacyjnej. To będzie być może ogłoszenie przyczyn transformacji, to będzie wyjaśnienie tego słownictwa do całej organizacji, również do tych zespołów czy osób, które bezpośrednio w sposób zwinny nie będą jeszcze pracować. Tu jest szereg rzeczy, które typowo, albo w HR, albo obok HR jakoś są skojarzone i szereg narzędzi wewnętrznych do tego, żeby te informacje na temat zmiany propagować. Tutaj jest jakby dwojako możliwa rola. Z jednej strony to będzie posiadanie kontroli nad pewnymi narzędziami, na przykład umożliwienie publikacji pewnej informacji w Intranecie albo wysłanie maila do wszystkich pracowników. To też będzie ważna rola w tym, żeby takim pół zewnętrznym okiem, takim mniej zaangażowanym bezpośrednio w zmianę, być może okiem, które nie do końca jeszcze łapie te wszystkie żargony związane z agile, żeby pomóc ten komunikat sformułować, pomóc go dopieścić, żeby on trafiał do odbiorcy, trafiał do wszystkich pracowników w sposób zrozumiały. Jacek: Innym przykładem działań, których można się spodziewać HR, to są takie rzeczy być może trochę prozaiczne, ale jednak takie najbardziej właściwe, jeśli chodzi o HR. Czyli na przykład może się pojawić konieczność przeformułowania umów, jakie mamy z pracownikami. Czyli na przykład może się pojawić konieczność zmiany stanowisk konkretnych osób, a czasem wprowadzenia nowych stanowisk. Przykładowo, jeżeli firma decyduje się na podejście scrumowe, pojawiają się, chociażby takie role jak Scrum Master czy Product Owner i bardzo często te role nabierają takiej bardziej formalnej struktury, czyli pojawiają się na umowach i to bardziej, jeżeli mówimy o roli tylko często właściwie już o stanowisku. Stąd dział HR staje się takim najbardziej sensownym działem i najczęściej też na bazie moich doświadczeń jest do dział, który po prostu takim uporządkowaniem –  nazwijmy to kwestii formalnych – zajmuje. Kuba: Następną rzeczą, to akurat nie zawsze, nie w każdej firmie się zdarzy – to może być koordynacja zmiany. W niektórych organizacjach za transformację i za taką powiedzmy koordynację, doprowadzenie do tego, że istnieje jakiś zespół zarządzający zmianą. Doprowadzenie do tego, że ta zmiana też ma jakieś konkretne, wymierne kroki. W niektórych firmach będzie to jakiś lider zmiany z danego zespołu, na przykład IT lub zespołu produktowego, ale spotkaliśmy się obaj z Jackiem z przypadkami, gdy osobą, która nakręca zmianę, koordynuje zmianę, też tak bardzo op

Techniki wizualizacji, które polecamy. Jak dobrze przeprowadzić wizualizację pracy w Sprincie. Wyjaśniamy jak korzystać ze Scrum Boarda. Dajemy Ci także kilka innych porad związanych z wizualizacją, a także wskazujemy to, czego raczej unikać. Działania te pomogą Ci dobrze przeprowadzić Sprint. Porządny Agile · #041 – Wizualizacja pracy w Sprincie Zobacz wersję wideo 📄 Transkrypcja podcastu „Wizualizacja pracy w Sprincie” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Kuba: Niedawno przeprowadzaliśmy badanie wśród naszych słuchaczy – ankietę, którą do Was wysłaliśmy. Dzięki za odpowiedzi. Dzięki jeśli Ty odpowiedziałeś, odpowiedziałaś, a jeśli nie, to ten odcinek i tak będzie sponsorowany przez tę ankietę i przez tych z Was, którzy odpowiedzieli, ponieważ między innymi poprosiliśmy o propozycję tematów. Dostaliśmy tych odpowiedzi bardzo dużo. Próbowałem policzyć ile odcinków mamy gotowych dzięki tym propozycjom, ale się nie doliczyłem. Na pewno z rok nagrywania jak nic. Spośród tych wszystkich podpowiedzi, wszystkich tych sugestii wybraliśmy jeden temat i porozmawiamy dzisiaj o wizualizacji pracy w Sprincie. Jak korzystać z boarda i czego unikać. Jacek: Wizualizacja pracy, którą konkretny zespół w danym odcinku czasu wykonuje, jest bardzo popularną techniką rozszerzającą, na przykład Scruma. Bardzo często wręcz dochodzi do takich pomysłów, żeby nazywać to Scrum board lub takie inne nazwy, które wskazywałyby na to część Scruma. No wyraźnie tutaj chcielibyśmy tutaj zaznaczyć, że jakby co do zasady nie jest i możesz z tej praktyki tej wizualizacji skorzystać tak naprawdę właściwie niezależnie od tego, jakim sposobem pracujesz. Kuba: Warto sobie na początek porządnie zdefiniować, dlaczego wizualizacja pracy to jest dobry pomysł? Trochę może przerysowana metafora, ale jeśli pracujemy w fabryce aut, no to te auta produkowane, kolejne kawałki karoserii, dokręcane koła, domontowywane drzwi – widać gołym okiem. I zarówno osoby, które pracują w ramach ekip, które to auto montują jak i zarządzający, te auta po prostu widzą, że one powstają. Dosyć łatwo zobaczyć też auto na swoich kołach wyjeżdża. Może jeszcze taka inna metafora, równie może daleko od pracy kreatywnej. Jak koszę trawnik, lubię go kosić, no to widzę, gdzie jest trawa, która jest jeszcze nieskoszona i widzę tę trawę, która jest skoszona. Gołym okiem widać rezultat, łatwo jest oszacować czy ocenić ile jeszcze pracy zostało do wykonania. W pracy kreatywnej, a taka zazwyczaj jest realizowana w podejściu zwinnym. Czy to jest wytwarzanie oprogramowania, czy to jest, szerzej patrząc, tworzenie jakiegoś produktu, czy to cyfrowego, czy jakiejś koncepcji, czy jakiejś usługi, rozwiązania? Bardzo często ta praca jest niewidoczna, a zwłaszcza jest niewidoczna w trakcie. Dopiero już jak to wszystko działa to być może mamy faktycznie fizyczny produkt, który możemy na jakimś podsumowaniu iteracji pokazać. Ale, póki praca przebiega, to jest bardziej koncepcja, projekt, być może kawałek kodu, testy. To są wszystko bardzo nienamacalne rzeczy. I tutaj bardzo dobrze działa zasada, żeby tę pracę symbolicznie pokazać. Wykazać. Pokazać ją w postaci jakichś umownych jednostek, na przykład jakiejś kartki, listy, czy czegokolwiek co nam pokaże, że ta praca jest, czym ona jest. Pokaże też ogarnąć całą rzeczywistość. Coś, co się wydaje dosyć oczywiste, w takiej pracy indywidualnej, jak mam do zrobienia dziesięć rzeczy, to to jest na tyle dużo, że nie jestem w stanie tego ogarnąć, więc zrobię sobie jakąś listę, pewnie gdzieś w miejscu dostępnym dla mnie. Tak zespoły chętnie wchodzą w praktykę właśnie wizualizacji poprzez ujawnienie całej pracy, symboliczne jakieś zobrazowanie. Parę z tych rzeczy, o których wspomniałem, czyli pokazanie co jest w ogóle do zrobienia, pokazanie, na jakim etapie jesteśmy. Być może pokazanie kto, na jakim etapie pracuje, żeby też usprawnić przebieg informacji czy komunikację między nami. To jest bardzo proste, jak ja o tym opowiadam, ale w niektórych zespołach być może potrzebna jest ta refleksja – po co to w ogóle robimy, co ma nam to dać, czemu i komu ma to służyć? No i jeśli tak się to ujmie, to zazwyczaj zespoły szybko wpadają, że faktycznie jest to pomocne podejście. Jacek: Gdyby ktoś potrzebował pomimo tej opowieści Kuby zbudować sobie większą empatię, to warto zrobić sobie taki eksperyment – o ile oczywiście pracujecie w biurze. Wejść sobie do przykładowego, dowolnego pokoju, gdzie ludzie pracują w sposób kreatywny – czyli piszą oprogramowanie, tworzą jakieś analizy, pracują na danych czy są po prostu kreatywni. No i spojrzeć na nich jak pracują na komputerze. Widzimy tylko ludzi, którzy siedzą przy komputerze, kompletnie nie wiemy, czy teraz pracują, czy się nad czymś zastanawiają, czy to jest przerwa na Facebooka. I tak naprawdę trudno jest ocenić czy coś namacalnego powstało, w jakim to jest etapie. Tę metaforę zastosowałem ostatnio na szkoleniu i na koniec szkolen