Porządny Agile

Co można zrobić, by zaangażować zespół w rozwiązywanie problemów? Jedną z metod jest „Take it to the team”, którą polecamy nawet osobom zaczynającym pracę w rolach zwinnych – kiedy są w tak zwanej tranzycji. Dodatkowo mamy pięć innych porad, które pozwolą zaangażować zespół by wspólnie rozwiązać powstałe problemy. Pomocne będą też aspekty,  aspekty, które bierzemy pod uwagę, kiedy zastosować daną metodę, a kiedy nie. Spis treści Take it to the teamAlternatywy do Take it to the teamKryteria, które pomagają określić, w jakim stopniu angażować zespół w rozwiązywanie problemów📄Transkrypcja podcastu „Jak angażować zespół w rozwiązywanie problemów?” Porządny Agile · #040 – Jak angażować zespół w rozwiązywanie problemów? Take it to the team Tego rodzaju wskazówka jest szczególnie pomocna dla osób, które dopiero rozpoczynają pracę w rolach zwinnych i znajdują się w procesie przejścia z bardziej klasycznych modeli zarządzania. Osoby z doświadczeniem w klasycznym zarządzaniu np. Project Managerowie, często przenoszą nawyk samodzielnego rozwiązywania problemów do pracy z zespołem zwinnym. Działa też obawa, że zespół może nie do końca brać odpowiedzialność, więc lider bierze sprawy w swoje ręce. Dlatego warto budować nawyk: przedstawiać problem zespołowi, wspólnie go definiować i szukać rozwiązań razem.  Czasem zespół potrafi zaproponować coś, na co lider czy Scrum Master sam by nie wpadł i to bywa naprawdę odkrywcze. Co więcej, zespół chętniej wdraża rozwiązanie, które sam wypracował, właśnie dlatego, że to jest ich pomysł. Technika „Take it to the team” nie jest uniwersalnym rozwiązaniem, które zawsze działa. Przerysowanym przykładem byłoby odbijanie każdego pytania z powrotem do zespołu, niezależnie od kontekstu. Nawet jeśli zespół prosi o opinię, sugestię lub radę, odpowiadamy pytaniem. To pułapka opisana w „Labiryntach Scruma” jako postawa „Scrum Mastera, który zachowuje się jak coach”. Dlatego chcemy podkreślić: to nie technika, która sprawdzi się w każdej sytuacji. Przyjrzymy się, kiedy ta technika ma sens, a kiedy niekoniecznie. Podzielimy się też tym, jakie czynniki warto rozważyć, decydując o jej zastosowaniu i w jakim zakresie. Nie jest to jedyna możliwa droga w pracy z zespołem, ale mamy kilka sensownych alternatyw.  Zobacz wersję wideo Alternatywy do Take it to the team 1. Rozwiązanie problemu poza zespołem Choć zaczęliśmy od pozytywnego obrazu zespołu samodzielnie rozwiązującego problemy, to nie znaczy, że każde działanie poza zespołem jest z góry błędem. W praktyce wiele decyzji faktycznie zapada poza zespołem. Przykładem są decyzje o przejściu na zwinne podejście, wyborze narzędzi, technik czy frameworków. Takie decyzje zwykle zapadają na poziomie organizacji, nie zespołu. Często zespoły nie uczestniczą w tym procesie ani nie są o niego pytane. To ma swoje zalety i wady. Warto uważać na pułapkę myślenia, idąc tropem pułapki z „Labiryntów Scruma” że tylko to, co powstaje w zespole, jest wartościowe. Są decyzje, które muszą zapaść poza nim i to nie czyni ich gorszymi. W niektórych sytuacjach to liderzy organizacji muszą wziąć odpowiedzialność i spojrzeć na całość. To oni inicjują zmianę, a zespoły podejmują decyzje na dalszych etapach. Czasem ten pierwszy impuls, decyzja o zmianie musi pojawić się poza zespołem. Kiedy zatem to podejście jest zasadne? Wtedy, gdy w grę wchodzi duża zmiana organizacyjna, wymagająca decyzji lidera z szeroką perspektywą, który otwiera drogę do dalszych, kolejnych decyzji w zespołach niższego szczebla.  Warto też wspomnieć o sytuacji, w której zespół otrzymuje do rozwiązania konkretny problem. Jednak decyzje dotyczące poziomu ryzyka i granic, których nie można przekroczyć, zapadają poza zespołem. Przykładem może być środowisko regulowane, w którym kierunek działań wyznaczany jest przez osoby zarządzające organizacją, a nie przez sam zespół. Decyzje podejmowane poza zespołem nie muszą być złe, stają się problematyczne dopiero wtedy, gdy zespół nie rozumie, skąd się wzięły. Dotyczy to np. ograniczeń procesowych, architektonicznych, regulacyjnych czy organizacyjnych przekazywanych zespołowi z zewnątrz. Tego typu decyzje nawet podjęte poza zespołem są łatwiejsze do przyjęcia, jeśli znany jest ich kontekst. Pomaga wtedy zrozumienie ryzyk, ograniczeń i rozważanych wcześniej alternatyw. 2. Rozwiązują problem tylko z częścią zespołu To podejście pośrednie zespół bierze udział w decyzji, ale nie w pełnym składzie. To podejście pośrednie, zespół bierze udział w decyzji, ale nie w pełnym składzie. Dobór osób zależy od kontekstu. Najczęściej są to osoby z większym doświadczeniem ogólnym lub związanym z danym produktem czy systemem. Zwykle nie jest to formalnie nazwane, ale naturalnie przyjmowane. Czasem decyzja wynika z chęci oszczędzenia czasu całego zespołu, innym razem z przekonania, że mniej doświadczone osoby nie są jeszcze gotowe na przykład do decyzji architektonicznych, podczas gdy osoby z wieloletnim stażem potra

Jak powinien wyglądać poprawny Backlog Produktu? Kogo warto zaangażować do tego? Do czego należy być przygotowanym? Mamy dla Ciebie sześć rad dzięki którym Twój Backlog Produktu będzie porządny. Dzięki nim będziesz wiedział/a na co zwrócić uwagę, a co jest mniej ważne. Porządny Agile · #039-Porządny-Backlog-Produktu Backlog Produktu odgrywa istotną rolę w realizacji celów, jakie stoją przed Zespołem Scrumowym, dlatego podzielimy się z Tobą 6 radami, które zebraliśmy podczas naszych doświadczeń w pracy w środowiskach zwinnych. Spis treści Czym jest Backlog Produktu?Jak pracować z Backlogiem Produktu?📄Transkrypcja rozmowy „Porządny Backlog Produktu” Zaczniemy najpierw od tego, czym Backlog Produktu jest, następnie powiemy m.in. o tym, jak się przygotować do jego tworzenia oraz czy warto eksperymentować z jego formą. Poruszymy też kwestię asertywności przy dodawaniu elementów do tej listy oraz jej regularnych przeglądach. Czym jest Backlog Produktu? Zgodnie z Przewodnikiem po Scrumie Backlog Produktu jest pewną uporządkowaną listą wszystkiego, co w danym konkretnym momencie wiemy o rozwoju produktu. Za jej utrzymanie odpowiedzialny jest Product Owner. Od siebie dodamy, że istotne jest uporządkowanie tej listy wg priorytetów, jakimi będziemy się zajmować i po prostu musimy ustalić kolejność poszczególnych jej elementów. Nie ma tu miejsca na podział na must, should czy could, mamy się po prostu zdecydować, co będzie na pierwszym miejscu, co na drugim, a co na kolejnych. Oczywiście w trakcie pracy te rzeczy mogą zmieniać miejsca np. w związku z nowymi informacjami, które do nas napływają. Istotne jest też, żeby treść w Backlogu niosła za sobą jakieś informacje, umożliwiając zespołowi rozpoczęcie pracy. Unikajmy ogólnych haseł, z których nic nie wynika. Jest to istotne, gdyż jest to jedyne źródło, z którego czerpiemy informacje, co jest do zrobienia i w jakiej kolejności. Dzięki temu nie ma zamieszania, bo rzeczy są rozproszone po kilku listach i nie wiadomo, czym się kierować. Jak pracować z Backlogiem Produktu? 1. Zaangażuj Deweloperów w tworzenie Backlogu Produktu W naszej pracy często spotykamy się z sytuacją, w której jedyną osobą, która dba o stworzenie i utrzymanie Backlogu Produktu, jest Product Owner. To niestety może prowadzić do sytuacji, że sporą część jego pracy pochłaniają właśnie te obowiązki. A to nie jest przecież jedyna jego rola, ma on więcej zadań, na które po prostu nie starcza mu czasu, np. na rozmowy z klientami. Inną konsekwencją takiego stanu rzeczy jest pewnego rodzaju odcięcie zespołu od niezwykle istotnej wiedzy produktowej, co może pociągnąć za sobą brak zrozumienia, co jest do zrobienia. Ponadto Product Owner staje się wąskim gardłem w pracy z Backlogiem. Aby uniknąć tych problemów, to warto zadbać o współpracę Deweloperów z Product Ownerem przy tworzeniu i zarządzaniu Backlogiem. Nie tylko Właściciel Produktu będzie odciążony, ale również deweloperzy będą mieli lepsze zrozumienie tego, nad czym pracują. 2. Bądź przygotowany na kolejny Sprint Warto wiedzieć, czym będziemy się zajmować w najbliższym czasie obejmującym kolejny Sprint. Widzimy, że w zespołach, gdzie brak patrzenia poza obecny Sprint, planowanie kolejnych kroków, jest o wiele bardziej wymagającym zajęciem. Zaczyna się wymyślanie, kreowanie i rzeźbienie, co moglibyśmy zrobić. Lepiej, jeśli to zadzieje się wcześniej, w procesie doskonalenia Backlogu Produktu. Świadomość tego, co będziemy realizować w kolejnym Sprincie, pozwala też szybko wyłapać ewentualne zależności zewnętrzne i odpowiednio wcześnie zapobiec opóźnieniom. Co więcej, te problemy lubią się potem przenosić na kolejne Sprinty, a w następstwie kumulować i prowadzić do chaosu. Dlatego naprawdę warto poświęcić trochę czasu na Refinement, nawet kosztem realizacji zadań w danym Sprincie. Oczywiście  to nie gwarantuje sukcesu biznesowego tego, co robimy czy też 100% skuteczności, jednak niweluje przyczynę wielu problemów już u źródła. 3. Miej przygotowaną kolejną rzecz do zrobienia Ta rada jest mocno powiązana z poprzednią, ale tu konkretnie wiemy, czym zajmiemy się w następnej kolejności. Mamy tu na myśli jakiś większy kawałek produktu czy większą funkcjonalność, którą możemy określić jako kolejny krok na road mapie. Mimo że brzmi to bardzo oczywiście, to wciąż widzimy, że są zespoły, które nie mają takiego planu i nie są w stanie przewidzieć najbliższego większego kroku. Być może ten plan nawet jest, ale niestety tylko w głowie Product Ownera i interesariuszy. Natomiast świadomość tego, w jakim kierunku idziemy, ułatwia podejmowanie decyzji w związku z tworzeniem produktu, jeśli zmieniają się plany biznesowe, jak i ma ogromny wpływ na motywację do pracy. Co więcej, jesteśmy w stanie myśleć o kwestiach technologicznych bardziej przyszłościowo, wiemy, jak tworzyć obecne kawałki produktu, aby wspierały te, które dopiero powstaną w kolejnych Sprintach. Rzecz jasna, nie chodzi tu o posiadanie perspektywy rok do przodu, zaplanowanej i dobrze rozpisanej.

Co możesz zrobić, żeby przekonać swojego klienta do pracy w sposób zwinny? Jak skutecznie przedstawić mu zalety pracy zwinnej? Dajemy Ci pięć porad, które pomogą dobrze sprzedać agile, a także otwarcie mówimy, kiedy gra nie jest warta świeczki. Porządny Agile · #038 – Jak sprzedawać agile? Zobacz wersję wideo Dodatkowe materiały artykuł Jacka na stronie jacekwieczorek.pl 📄Transkrypcja podcastu „Jak sprzedawać agile?” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Jacek: W dzisiejszym odcinku chcemy porozmawiać o tym, jak sprzedawać agile, jak sprzedawać zwinność. Tłem do tego odcinka są historie, których wielokrotnie doświadczyłem pracując w software house, gdzie zarówno ja, jak i generalnie rzecz ujmując software house stawał przed taką sytuacją, w której trzeba opowiedzieć klientowi czym jest praca zwinna. W dzisiejszych czasach generalnie jak wejdzie się na dowolny software house no to ta zwinność jest mocno dostrzegalna już na poziomie strony internetowej. Natomiast dla klienta może to znaczyć wszystko i nic. Stąd nie wystarczy powiedzieć, że jesteśmy zwinnym software house czy, że pracujemy w sposób zwinnym z klientem zewnętrznym. Warto nauczyć się i przemyśleć jaką w ogóle mamy strategię inspirowania klienta zwinnością i w jaki sposób chcemy klienta do tego rodzaju pracy zachęcać i przekonywać. Kiedy mówię o relacji klient zewnętrzny, a dostawca mam na myśli taki główny jeden scenariusz. Jest to scenariusz, w którym jesteśmy software housem i dostarczamy klientom zewnętrznym konkretne oprogramowanie najczęściej skrojone na miarę, a czasem jest to taki wariant, w którym mamy jakieś produkt pudełkowy i stanowi on pewną bazę. Natomiast już konkretnie pod klienta, pod jego potrzeby ten produkt rozbudowujemy czy konfigurujemy. Kuba: A jeżeli czujesz, że taki odcinek nie dotyczy Ciebie, to bardzo liczę na to, że, mimo że tematyka jest dosyć dookreślona i może być niszowa, to liczę na to, że te historie o tym jak sprzedawać agile w takich relacjach klient-dostawca mogą być również inspirujące dla innych przypadków, gdy wewnątrz organizacji trzeba do tego agile`a przekonać czy to biznes, czy zespół z którym współpracujemy czy ogólnie sprzedać agile’a do firmy czy do zarządzających. Więc pomimo tego, że jesteśmy bardzo dookreśleni i będziemy się trzymać tych realiów współpracy z klientem, no mimo wszystko liczę na to, że będzie też do wyjęcia również dla osób, które w tej relacji przynajmniej teraz nie pracują. Jacek: Przygotowaliśmy pięć konkretnych porad, które z naszej perspektywy warto spróbować, warto wcielić w życie i przejdziemy po kolei po tych poradach. Pierwsza porada co do której się zgodziliśmy z Kubą to jest porada, w której mówimy, że warto skupić się na sprzedawaniu korzyści, a nie konkretnie na przykład Scruma, czyli konkretnego narzędzia. Z czego wynika taka porada? Powodów jest co najmniej kilka. Po pierwsze, kiedy będziemy sprzedawać klientowi Scruma jako takiego, no to możemy trafić na sytuację, w których klient pracował już wcześniej przy użyciu tego frameworka. No i może mieć jakieś swoje już doświadczenia, jakiś swój punkt widzenia. Super, jeżeli są to pozytywne doświadczenia. Natomiast no ten bardziej ciemny scenariusz to jest ten, w którym klient pracował w kiepskim Scrumie, który umówmy się nie był, nie dostarczał wartości. No więc jak klient usłyszy Scrum, no to może zareagować alergicznie na zasadzie – my już pracowaliśmy Scrumem, przekonaliśmy, to nie działało, to była strata czasu i tak dalej i tak dalej. Tak więc to jest pierwszy powód. Drugi powód dla którego moim zdaniem warto skupić się na korzyściach pracy w Scrumie, a nie na samym operowaniu tym słownictwem jest to, że po prostu te sformułowania, których będziemy używać mogą być dla klienta po prostu niezrozumiałe. Czyli nie możemy się skupić na takich ładnych okrągłych zwrotach jak transparencja, inspekcja, adaptacja, Backlog Sprintu, Product Owner, Scrum Master. I dla nas to może być oczywistość co te rzeczy znaczą i absolutnie jasne pojęcia. Natomiast Backlog produktu może nie znaczyć nic. Natomiast no to nie jest aż tak, że każdy klient podczas rozmowy będzie na tyle odważny czy otwarty, żeby dopytywać o te rzeczy. Tak więc możemy mieć takie piękne poczucie, że idealnie i perfekcyjnie tłumaczymy Scruma, natomiast dla klienta to będzie absolutny bełkot w takim sensie, jakieś buzz wordy, jakieś specjalistyczne słownictwo, z którego nic nie wynika. Trzeci powód, który przychodzi mi do głowy, jest taki, że z perspektywy samej komunikacji, moim zdaniem lepiej jest powiedzieć klientowi jaką konkretną korzyść uzyska pracując w Scrumie, niż opowiadać o tym, że jakiś tam element Scruma będzie wykorzystywany. Czyli przykładowo, zamiast mówić klientowi, że praca w Scrumie będzie transparentna, co tak do końca nie wiadomo co będzie znaczyć dla klienta. Moim zdaniem lepiej jest powiedzieć, że pracujemy w przejrzysty sposób i cały nasz proces pracy jest gotowy do wglądu.

Scrum Master to osoba, która wciąż musi się rozwijać. Masz już pewien poziom wiedzy oraz doświadczenia w tej dziedzinie i zastanawiasz się co dalej? W tym odcinku rozmawiamy o dalszym rozwoju zawodów zwinnych. Co możesz zrobić, by nabyć nowe doświadczenia i kompetencje? Rozmowę dedykujemy osobom, które są w pozycji lidera zmiany. Dowiesz się zatem jak pogłębić, poszerzyć i ugruntować podejście zwinne na tych bardziej zaawansowanych poziomach u siebie lub u osób, na których rozwój zawodowy masz wpływ. Zobacz wersję wideo Dodatkowe materiały Jak się rozwijać w roli Scrum Mastera? Nasze konsultacje on-line 📄 Transkrypcja podcastu „Wyszkoliliśmy się ze zwinności i co dalej?” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Kuba: Wyobraźmy sobie taką sobie taką sytuację, że jesteśmy w firmie, w której podejście zwinne jest stosowane od jakiegoś czasu. Mamy doświadczenie w pracy w kilku zespołach zwinnych. Mamy już Scrum Masterów, którzy od jakiegoś czasu to praktykują. Mamy Product Ownerów, którzy już wiedzą jak w podstawowy sposób zarządzić Product Backlogiem. W skrócie. W naszej firmie pojawiły się pierwsze zręby kompetencji zwinnych. Parę osób było na różnych szkoleniach, może mieliśmy szkolenia wewnętrzne. Może już parę osób odwiedziło konferencje. Czyli zrealizowaliśmy coś, co bym nazwał absolutnym fundamentem tego jak rozwijać kompetencje zwinne na początku transformacji, czy na początku wprowadzania podejścia zwinnego. Może w firmie istnieje już jakaś biblioteczka z książkami zwinnymi? Jest parę podstawowych kroków zrealizowanych. I wtedy pojawia się podstawowe pytanie, co dalej z rozwojem zawodowym w zawodach zwinnych? Co dalej z rozwojem zawodowym Scrum Masterów, Product Ownerów, być może Agile Coachy – jeśli ich mamy, być może managerów, którzy chcą się dopasować do podejścia zwinnego. O tym dzisiaj porozmawiamy w tym odcinku podcastu Porządny Agile. Jacek: W szczególności ten odcinek chcemy skierować do osób, które są aktualnie w pozycji lidera zmiany. Może są członkami zespołu zarządzającego zmianą? Może są na stanowisku dyrektorskim i odpowiadają za rozwój kompetencji osób, które podlegają? Z innej perspektywy patrząc osoby, które pracują we wszelkiego rodzaju nazwijmy to centrach agile, czyli w miejscach, które są odpowiedzialne w organizacji za rozwój kompetencji zwinnych w organizacji oraz mamy na myśli też takiego zaawansowanego Scrum Mastera bądź Agile Coacha, który wszystkie te rzeczy, które Kuba przed chwilą wymienił – odhaczył już ze swojej listy i zastanawia się co dalej dla mnie, co jeszcze mogę zrobić, w którą stronę mogę się rozejrzeć, żeby zdobyć nowe doświadczenia i kompetencje. Kuba: Bardzo podobną tematykę poruszyliśmy w drugim odcinku Podcastu: „Jak się rozwijać jako Scrum Master”. Ten odcinek bardzo świadomie chcemy przesunąć w bardziej w perspektywę organizacji. Wymienimy w dalszej części nagrania, praktyki, które przychodzą nam do głowy jako takie wartościowe i warto wprowadzić do swojej organizacji. Czy to z perspektywy zarządzającego, czy to z perspektywy Scrum Masterów czy Agile Coach’y, którzy mogą zainspirować pozostałych do tego, żeby ich spróbować? Być może jesteś inną osobą niż te wymienione przykładowi słuchacze przez Jacka. Jeśli jesteś na początku swojej drogi zawodowej w roli agile, albo w ogóle zaczynasz tego słuchać, zakładamy, że to też może być dla Ciebie inspiracja. Natomiast być może inspiracja na takie dalsze kroki niż te, które są teraz przed Tobą. Bo teraz rozmawiamy o tym jak pogłębić, poszerzyć i ugruntować podejście zwinne na tych bardziej zaawansowanych poziomach. Jacek: I mamy z Kubą przygotowanych pięć bardzo konkretnych porad co można zrobić w tych kolejnych krokach rozwijania się. Te pięć porad przedstawimy. Pierwszą poradą, którą dla Ciebie mamy jest porada, w której zachęcimy do ustawienia pewnej relacji podążania za doświadczonym Scrum Masterem. Co tutaj mam na myśli? Być może w Twojej organizacji istnieją już doświadczeni Scrum Masterzy, którzy mają doświadczenie w pracy z kilkoma zespołami, z różnymi produktami. Idealnie, gdyby byli to Scrum Masterzy, którzy pracowali też wcześniej w innych organizacjach. Jeżeli jesteś w tak komfortowej sytuacji, to bardzo sensownym pomysłem jest zainicjowanie modelu, w którym osoby mniej doświadczone jako Scrum Master podążają za Scrum Masterem bardziej doświadczonym. I co mam na myśli mówiąc podążają? To jest zarówno uczestnictwo we wszelkiego rodzaju wydarzeniach scrumowych. Uczestnictwo wraz z tym Scrum Masterem na wszelkiego rodzaju aktywnościach jak warsztaty, jakieś takie moderowane sesje, ale też towarzyszenie takiemu Scrum Masterowi w jego codziennej pracy. Przykładowo, jeżeli ten Scrum Master idzie rozwiązać jakiś problem, jakąś blokadę dla zespołu i musi porozmawiać z jakimś na przykład managerem, który jest w stanie tę blokadę zlikwidować. No to wtedy ten mniej doświadczony Scrum Master jest z tym bardziej doświadczonym na tej

Dowiedz się o różnicach pomiędzy pracą w obu podejściach w sposób zwinny. Czym jest projekt, a czym produkt i jak my rozumiemy w nich zwinność – jakie są różnice między nimi? Czy w ogóle istnieje jakaś gotowa lista kontrolna, która pozwala sprawdzić zwinność? Jaką w tym wszystkim odgrywa rolę lider projektu? O tym mówimy w 36. odcinku podcastu Porządny Agile. Porządny Agile · #036 – Zwinne projekty i produkty Zobacz wersję wideo Dodatkowe materiały, które wspominamy w nagraniu: Praca na termin w agile Konsultacje 📄Transkrypcja podcastu „Zwinne projekty i produkty” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Kuba: W tym odcinku chcielibyśmy opowiedzieć trochę o różnicach między podejściem projektowym, a produktowym i pracą w obu tych podejściach w sposób zwinny. Treścią tego odcinka będzie zdefiniowanie najpierw pojęć, czyli co rozumiemy pod projektem i co rozumiemy pod rozwojem produktu. Podzielimy się też naszym zrozumieniem zwinności w projektach i produktach. Na końcu przedyskutujemy subtelne różnice i też trochę w pewnym sensie zagrożenia jakie są między tymi podejściami. Natomiast coś o czym ten odcinek na pewno nie będzie, to nie będzie to krytyka ani porównywanie wyższości jednego podejścia nad drugim. W szczególności chcemy uniknąć krytykowania słabych projektów i przeciwstawiania tego dobremu podejściu produktowemu i na odwrót. Słabe podejście produktowe kontra świetne projekty. Od tego chcemy się dystansować. Mamy nadzieję, że nam się w tym odcinku to uda. Jacek: Tak. Chcielibyśmy zacząć generalnie od takiego zdefiniowania sobie o czym tak naprawdę mówimy. Jeżeli myślimy o projektach w trakcie dzisiejszego odcinka, no to myślimy o projektach, że jest to pewne tymczasowe przedsięwzięcie, które tworzymy mając jakiś konkretny cel z tyłu głowy. To może być wyprodukowanie jakiegoś unikalnego produktu, to może być wyprodukowanie jakiejś usługi lub jakiś rezultat, który chcemy uzyskać. Projekty w naszym rozumieniu dzisiejszej rozmowy zawsze mają początek, zawsze mają koniec i jakiś konkretny zakres do zrealizowania. Mamy też przeznaczone jakieś konkretne zasoby, w tym zasoby ludzkie, żeby taki projekt zrealizować. Kuba: Mówiłeś Jacek w naszym rozumieniu. Natomiast to nie jest tak, że teraz we dwóch ukuliśmy jakąś definicję projektu. Żeby też być bardzo poprawnym metodycznie w tym miejscu, po prostu posiłkowaliśmy się definicją projektów. Akurat skorzystaliśmy z materiałów udostępnianych przez Project Management Institute. Jacek: Ok. Czyli tak będziemy definiować projekt. Jak zdefiniujemy produkt Kuba? Kuba: Produktu akurat nie będziemy definiować, bo jest to dosyć abstrakcyjne pojęcie. Natomiast takie podejście rozwoju produktu, to coś mam przygotowane jako swoją definicję. Tutaj podejście produktowe, czy zarządzanie rozwojem produktu to szereg działań podejmowanych, żeby dostarczyć na rynek coś, co spełnia życzenia, albo potrzeby klienta. I to jest bardzo konkretna definicja, chociaż ona może być dosyć wieloznaczna. Zdajemy sobie z tego sprawę. Mówimy tutaj o szeregu różnych działań zarządczych, wymyślania kreacji, rozwoju i utrzymania czegoś, co odpowiada na potrzeby klienta. Jacek: W dobie dużej popularności zwinności zaczęliśmy się z Kubą zastanawiać po czym byśmy poznali czy zwinny projekt, czy zwinny rozwój produktu? Bardzo łatwo dzisiaj do zarządzania projektem dodać słowo zwinne, do zarządzania produktem dodać słowo zwinne. Na prawo, na lewo operować pojęciem, że realizujemy pewne projekty czy produkty w zwinny sposób. Tak więc przygotowaliśmy konkretną listę przykładów, które naszym zdaniem odróżniają projekty i produkty realizowane w sposób zwinny od projektów i produktów realizowanych w sposób nazwijmy to klasyczny. Kuba: Tak jak wstępnie zaznaczyłem, to nie jest rozmowa o tym, czy coś jest zwinnym projektem czy zwinnym produktem. Tylko po czym w ogóle poznajemy, że coś jest zwinne. Wcale tutaj nie chcemy rozróżniać, które z nich jest lepsze, przynajmniej w tej części rozmowy. Możecie potraktować to, jako taką budowaną przez nas check-listę. Bo to też nie jest tak, że usiedliśmy i nagle to wymyśliliśmy. To jest raczej efekt wszystkich naszych działań, podejść i też pewien sposób pracy, jeśli trafiamy do nowego zespołu, do nowej firmy i sobie sami chcemy sprawdzić, czy to co właśnie doświadczamy, co obserwujemy, pracę tego zespołu, którą mamy okazję zobaczyć na własne oczy, czy to jest praca zwinna czy nie. Jacek: Yhm. Kuba: Nie jest to takie trywialne. Zanim przejdziemy do konkretnie do tej listy. Bo też tworząc tę listę sami sobie zadawaliśmy trochę pytań. Nie istnieje nigdzie jakaś taka jedna jedyna słuszna lista. Łatwo o różne interpretacje tego, co to znaczy podejście zwinne. Również z zagrożeniami tej myśli. Możemy na przykład zbyt wąsko pewne rzeczy potraktować. Jeśli korzystamy ze Scruma to pracujemy zwinnie. Ale też na przykład stwierdzić – kurczę mamy zakres zdefiniowany na początku, albo termin, to na pewno nie jest

Łączenie ról w Scrumie – poznaj kilka możliwych kombinacji – ich plusów i minusów oraz zagrożeń, jakie mogą wynikać z wypełniania obowiązków dla dwóch stanowisk jednocześnie. Czy Product Owner powinien być jednocześnie Scrum Masterem? Jakie konsekwencje może mieć bycie członkiem Zespołu Developerskiego przy jednoczesnym pełnieniu innej roli? O tym w 35. odcinku podcastu Porządny Agile. Zobacz wersję wideo Dodatkowe materiały Współpraca Scrum Mastera z Product Ownerem 📄 Transkrypcja podcastu „Łączenie ról w Scrumie” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Kuba: Dzisiaj porozmawiamy na temat łączenia ról w Scrumie. Odcinek w sumie agendę ma bardzo prostą, ponieważ najpierw opowiemy Tobie o konkretnych kombinacjach łączenia ról i zagrożeń, jakie z tego mogą wynikać. I w drugiej części odcinka opowiemy o tym, jak do tego podejść – co można zrobić z tym w praktyce. Skupimy się konkretnie na łączeniu ról w Scrumie, więc porozmawiamy tylko o roli Product Ownera, Scrum Mastera i Zespołu Developerskiego. Zastanawialiśmy się chwilę z Jackiem na temat możliwych innych kombinacji, ale stwierdziliśmy, że wyłączymy je z zakresu tego nagrania. Jacek: Pewne ważne takie zastrzeżenie na początku tego odcinka jest takie, że te wszystkie historie, które przytoczymy, one mają bardzo różny kontekst i mamy przypadki też takie, które będą przeczyć temu, co powiemy w tym odcinku. Doszliśmy z Kubą do wniosku, że bardzo dużo zależy od talentu konkretnej osoby, która takie role łączy i chcielibyśmy, żebyś przez ten pryzmat spojrzał bądź spojrzała na ten konkretny odcinek. Kuba: Innymi słowy – wiemy, że są pojedyncze przypadki, które przeczą temu, co powiemy, natomiast my spróbowaliśmy czerpać na bazie naszych doświadczeń w pracy z zespołami i spróbować wyciągnąć coś, co jest w przybliżeniu zazwyczaj prawdziwe, ale nie zawsze prawdziwe. To przejdźmy do konkretnych kombinacji łączeń ról i i ich zagrożeń. Zaczniemy od tego, co wydaje nam się, że jest najczęstszym przypadkiem łączenia roli, czyli łączenie roli Scrum Mastera i członka Zespołu Developerskiego czy Scrum Mastera i Zespołu Developerskiego. Jacek: Tak, i każdą taką kombinację przedstawimy w plusach i w minusach – z naszej perspektywy, na bazie naszych doświadczeń. I jeśli mówimy o tej perspektywie łączenia Scrum Mastera i członka Zespołu Developerskiego, to z mojej perspektywy najpoważniejszym zagrożeniem jest to, że bardzo łatwo jest zatracić perspektywę pracy jako Scrum Master i skupić się bardzo mocno na procesie wytwarzania. I bardzo często takie sytuacje widzę w praktyce, gdzie członek Zespołu Developerskiego, angażując się w pomaganie zespołowi w realizacji Celu Sprintu, no, traci z pola widzenia obowiązki Scrum Mastera, no i po prostu zaprzestaje ich wykonywania, jako że pełne skupienie przeznacza na to, żeby po prostu wspierać zespół w tym, żeby jakieś tam założenie odnośnie do pracy na konkretny Sprint zostały zrealizowane. Kuba: Podobnym minusem do tego, co mówisz, mniej z perspektywy skupienia, a bardziej z perspektywy braku czasu jest, no właśnie, brak możliwości realizowania tej roli Scrum Mastera po prostu czasowo. „Chcę się skupiać, chcę mieć perspektywy różne, tylko po prostu kalendarz ma skończoną ilość godzin, ja mam skończoną ilość sił dziennie czy w tygodniu, no i po prostu nie mam czasu, żeby pełnić tę rolę łączoną, rolę Scrum Mastera i Developera jednocześnie, muszę wybierać, pomiędzy Celem Sprintu, między rozwiązywaniem jakichś impedimentów, pracą w community scrummasterskich w firmie, swoim rozwojem – to wszystko powoduje, że mam trudne wybory, wybieram tylko te rzeczy, które są absolutnie niezbędne do przetrwania zespołu. Że tak powiem, żyję z dnia na dzień, a takie jakieś bardziej angażujące mnie czasowo rzeczy zostają po prostu odłożone na potem, albo w ogóle są nierealizowane”. Jacek: Innym minusem, który dostrzegamy, jest to, że rozwijanie się w roli Scrum Mastera czy rozwijanie się w jakiejkolwiek innej roli członka Zespołu Developerskiego – niezależnie, czy to jest programista, analityk, marketingowiec, prawnik – po prostu zajmuje czas. I automatycznie chcąc wejść tak na poważnie w pełnienie roli Scrum Mastera, no to otwieramy sobie dwie ścieżki rozwoju, które są właściwie jakby… nieskończone. Zawsze można być lepszym, zawsze można wiedzieć więcej, zawsze można doświadczyć większej ilości sytuacji i przykładów, no i po prostu dla mnie to jest jakaś taka ścieżka pewnego kompromisu, no bo doba ma ograniczoną ilość godzin, no i z pewnych rzeczy na 100% będziemy musieli zrezygnować – albo z tej naszej takiej pierwotnej funkcji członka Zespołu Developerskiego, albo z roli Scrum Mastera i jest to bolesny wybór, a w konsekwencji powoduje, że nie będziemy tak doskonali w tych swoich rolach, jak moglibyśmy być, gdybyśmy mieli tylko jedną rolę na głowie, a nie dwie. Kuba: Ale to, co m

Czy zespoły pracujące zwinnie powinny mówić emocjach? Czy w Agile’u jest w ogóle miejsce na takie „miękkie” tematy? Jakie są dobre praktyki w temacie pracy z emocjami członków zespołu i jak zadbać o ten temat, aby konflikty, problemy i negatywne emocje nie były przeszkodą podczas pracy? O tym w 34. odcinku podcastu. Zobacz wersję wideo Dodatkowe materiały The Core Protocols 📄 Transkrypcja podcastu „Emocje w Agile” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Kuba: W dzisiejszym odcinku porozmawiamy o emocjach w podejściu zwinnym. W tej chwili czuję się dosyć zestresowany, że będę mówił o takim delikatnym temacie, a jednocześnie czuję się też podekscytowany, bo wiem, że wiele osób uznaje ten temat za ważny, a dosyć często pomijany i spodziewam się, że dostanę bardzo dużo wzmocnień, że tak trudny temat został poruszony. Jednocześnie troszkę boję się, że te osoby, które ten temat uznają za nieważny, dosyć brutalnie obejdą się z tym, że taki temat akurat wybraliśmy do podcastu. I specjalnie zacząłem od swoich emocji, żeby pokazać w tym odcinku, że te rzeczy są ważne i nawet osoby, które – przynajmniej część z Was może uznawać za doświadczonych czy może ekspertów w swoich dziedzinach – też mogą się czuć emocjonalnie inaczej niż tylko super z entuzjazmem albo supergotowi do natychmiastowej walki. Konkret. Jakie rzeczy będą w tym odcinku? Najpierw sobie trochę zdefiniujemy emocje i powiemy, dlaczego w podejściu zwinnym ten temat ma znaczenie. Zrobimy małe zastrzeżenie – o nim za chwilę, a potem już przejdziemy przez kilka rzeczy czy kilka praktyk, jak można zadbać o emocje w pracy w zespole zwinnym. Jacek: Gdy spojrzysz na „Manifest Agile”, no to akcent na ludzi i interakcje jest całkiem spory. I tym odcinkiem chcemy też zwrócić uwagę na to, że podejście zwinne to nie tylko produkt, to nie tylko twarde aspekty wytwarzania produktu, to nie tylko technologia czy wydajność, czy w ogóle trafianie z produktem na rynek, ale gdzieś tam cały czas są ludzie, a ludzie są emocjonalni. W sensie, nie możemy tego aspektu pominąć. To zastrzeżenie, o którym Kuba wspomniał przed chwilą, to właściwie tak na etapie ustaleń przed nagraniem, uznaliśmy, że obaj się pod tym podpiszemy, że jak powiem za siebie, wcale się nie czuję mocny w temacie emocji i tak, jak się zastanawiałem nad tym, jak wykorzystuję te kompetencje w praktyce, no to nabrałem tych kompetencji, uważam, na takim poziomie wystarczającym, żeby funkcjonować, ale spotkałem na swojej drodze masę osób, o których powiedziałbym, że są emocjonalni, że potrafią  dobrze nazywać swoje emocje i że też potrafią to wykorzystać w praktyce, tak więc w tym obszarze czuję się, że mam podstawową wiedzę, ale na pewno nie jest to jakiś zaawansowany poziom. Kuba: Ale tym bardziej właśnie czujemy, że skoro obaj jesteśmy tacy dosyć mało emocjonalni, to to, co mamy do przekazania zwłaszcza może być dobrą radą dla osób, które są – podobnie jak my – mniej emocjonalni, więc na pewno wiemy też, że poruszymy bardzo podstawowe rzeczy i podstawowe rady – takie aplikowalne praktycznie w każdym zespole i zwracające uwagę na te rzeczy w zasadzie u każdego, nawet podobnych osób do nas. A te emocje są potrzebne w podejściu zwinnym właśnie do tego, że mówimy o pracy zespołów ludzkich, a nie mechanizmów, procesów czy jakichś takich trybików w maszynie, które muszą chodzić niezależnie od tego, co ludzie czują czy jak się czują. Konkretnie nagrywamy teraz odcinek w czasach kwarantanny, mam nadzieję wszystkich osób siedzących w swoich domach – no i to jest czas trudny. Niektórzy mają problem z pracą, niektórzy się zastanawiają, czy firma przetrwa to wszystko – też każdy z nas będąc w jakichś tam sytuacjach rodzinnych ma bliskich, którymi być może musi się zająć – czy to są dzieci, czy to są współdomownicy – jest trochę zmartwień czy obaw o to, czy będziemy zdrowi, czy może ktoś u nas w rodzinie dalszej jest zdrowy, więc jest cała masa rzeczy, które powodują, że pewnie nie operujemy jako ludzie na 100% naszych możliwości i ten moment, to jest akurat taki obiektywny – prawdopodobnie wszyscy to mamy, ale w losowych momentach pracy różnych zespołów każdy z nas może mieć lepszy lub gorszy moment – i te emocje, które ze sobą przynosimy spoza pracy, ale też te emocje, które są w środku nas w czasie pracy – jakaś presja projektu, być może jakiś konflikt międzyludzki, być może jakieś tam słabsze relacje z kimś, które powodują, że po prostu te emocje rzutują na to, jak pracujemy. I teraz bardzo konkretne takie ostrzeżenie – tak spróbuję analitycznie, co nam grozi, jak na te emocje nie zwracamy uwagi. Zdecydowanie przede wszystkim gorzej nam się pracuje, uzyskujemy gorszą wydajność jako zespół, dlatego że poszczególne osoby, nie zwracając uwagi na te swoje emocje, mogą się wzajemnie ranić, mogą nie być wystarczająco czujne na pewne rzeczy,

Jak usprawnić pracę Zespołu zwinnego za pomocą dostępnych na rynku narzędzi? Jakie narzędzia fizyczne oraz elektroniczne mogą wesprzeć realizację codziennych zadań Scrum Mastera, Agile Coacha i innych członków zespołu? Zazwyczaj mówiąc o pracy zwinnej, nacisk kładzie się na współpracę zespołową, relacje międzyludzkie, techniki pracy czy tematy związane ze skalowaniem. My tym razem zejdziemy o poziom niżej i skupimy się na omówieniu konkretnych narzędzi, które wspierają pracę zespołów zwinnych. Spis treści Uporządkowane środowisko pracy zespołuEfektywne zarządzanie czasemWizualne zarządzanie spotkaniemWykorzystywanie najnowszych trendów w narzędziachUżycie narzędzi elektronicznych w optymalny sposób📄Transkrypcja podcastu „Narzędziówka w pracy zwinnej” 5 aspektów narzędziówki w pracy zwinnej Uporządkowane środowisko pracy zespołu Mamy tu na myśli przede wszystkim zapewnienie porządku i przejrzystości, jeśli chodzi o wszelkiego rodzaju artefakty, które wytwarza i kolekcjonuje zespół. Przykładem takiego artefaktu jest sensownie zebrana i przedstawiona wizja produktu. Nie wystarczy stworzyć wizji i zapisać jej gdzieś na dysku lub trzymać jako zdjęcie w pamięci telefonu, jeśli nic się z nią dalej nie dzieje. To ten typ artefaktów, które powinny być z zespołem przez cały czas, żeby móc się do nich odwołać podczas planowania, czy na przeglądach. To taki punkt odniesienia, który pokazuje, co robimy, jak funkcjonujemy i po co w ogóle istniejemy jako zespół. Wizja jest jednym z przykładów, gdzie warto wdrożyć taką postawę, natomiast dotyczyć to też powinno np. reguł czy umów pracy zespołowej lub Definition of Done.  To uporządkowanie, o którym mówimy, może występować w formie fizycznej, czyli w sytuacji, kiedy to zespół przebywa na wspólnej przestrzeni. Jednak może ono występować również w narzędziach on-line, co jest oznaką, że ktoś nad tym panuje.  Tutaj mamy pewne zastrzeżenie, że nie chodzi nam o to, aby na jedną osobę zrzucić obowiązek utrzymywania porządku. Zarówno w tym punkcie, jak i w innych, zależy nam na propagowaniu idei utrzymywania porządku, przejrzystości i zrozumienia tego, co robimy w ramach całego zespołu.  Uporządkowane środowisko to także zbieranie i dobre rozmieszczenie w przestrzeni zespołu wszystkich wytworów pracy zespołu nad produktem czy Backlogiem Produktu. Przykładowo, jeśli stworzymy Story Map, to nie chowamy jej do szafy lub w jakimś kącie pokoju. Traktujemy ją jak żywy dokument, który ma cały czas z nami funkcjonować. Przecież w toku kolejnych Sprintów mogą pojawiać się jakieś znaczące zmiany i dobrze mieć ten dokument pod ręką. Dla nas przykładem uporządkowanego środowiska pracy zespołu jest sytuacja, gdy miejsce, w którym pracuje zespół, jest wręcz oklejone dookoła różnego typu materiałami, jak: DoD, notatki z Retro, Story Map itd. Trudniej to zrealizować w Open Space, ale tu przychodzą z pomocą różnego rodzaju narzędzia on-line. Efektywne zarządzanie czasem W tym punkcie chcielibyśmy zacząć od jednego bardzo ważnego aspektu, jakim jest odpowiednie przygotowanie do spotkań i posiadanie planu czy też agendy spotkania. Powinniśmy ustalić strukturę spotkania, co chcemy osiągnąć, jakimi narzędziami i sposobami to osiągniemy, kto jest niezbędny, aby osiągnąć cel spotkania, czy potrzebujemy się jakoś przygotować na spotkanie i z czym chcemy wyjść ze spotkania. Te rzeczy nie tylko świetnie wpłyną na jakość samego spotkania, ale także na efekty naszej późniejszej pracy. Dobra struktura spotkania może zawierać mniej elementów niż te, które wymieniliśmy powyżej. Czasem w zupełności wystarczy kilka prostych haseł na flipcharcie czy np. na Miro. Może to być po prostu: „Jesteśmy tu po to, robimy to, chcemy osiągnąć to, agenda jest taka”. Krótko, a jednak wszyscy wiedzą, jaki jest cel, a samo spotkanie ma swój uzasadniony sens oraz określone ramy. Zwłaszcza ramy czasowe (tzw. timeboxy) są istotne i warto zaplanować, ile czasu poświęcimy na konkretne etapy spotkania. Łatwiej wówczas kontrolować przebieg spotkania i świadomie zarządzać czasem, jaki mamy do wykorzystania. Timeboxy służą też pewnej dynamice spotkań. Przykładowo, jeśli damy sobie dziesięć minut na wymyślenie pomysłów, to będziemy wymyślać je dziesięć minut. Jednak jeśli damy sobie pięć minut, to będziemy musieli się spiąć i pewnie w te pięć minut może wymyślimy 80% pomysłów, które wymyślilibyśmy w dziesięć minut. Zresztą zawsze można dać trochę więcej czasu, jeśli jest on jeszcze potrzebny.  W zarządzaniu timeboxami bardzo pomagają narzędzia do mierzenia czasu, które są widoczne dla wszystkich, gdyż nie trzeba się pytać, ile czasu jeszcze zostało. Może to być zwykły zegar lub jakiś minutnik ustawiony tak, aby każdy go dobrze widział. Z narzędzi on-line polecamy np. https://e.ggtimer.com, pokazujący upływ czasu zarówno w formie cyfrowej, jak i na pasku postępu.  Z fizycznych narzędzi popularny jest Time Timer. My czasem z niego też korzystamy i tu podzielimy się naszym trikiem na efektywne zarządzanie

Kryzysy. Czym dokładnie są? Jak sobie z nimi radzić przy wykorzystaniu podejścia zwinnego? Które sytuacje są dla firmy szczególnie niebezpieczne? Czy da się przeciwdziałać kryzysom i zwalczać je, zanim będzie za późno? O tym w 32. odcinku podcastu. Zrozumienie zarządzania kryzysem Przygotowaliśmy kilka przykładów sytuacji, które mieszczą się w pojęciu „kryzysu” i chcemy je najpierw omówić, aby zbudować wspólne zrozumienie tego, co mamy na myśli. Spis treści Zrozumienie zarządzania kryzysemWiele zmian w otoczeniu prawnym w krótkim czasieWejście silnego gracza na rynekNieprzewidywalne wydarzenia losoweDuże zmiany na lokalnym rynkuKluczowe cechy skutecznych zespołów działających w kryzysieDedykowany silny zespółMocny liderSkupienie zespołu na celuIteracje zapewniające rzeczywisty przyrost produktuPrzyłożenie odpowiedniej uwagi managementu📄Transkrypcja podcastu „Agile jako reakcja na kryzys” Wiele zmian w otoczeniu prawnym w krótkim czasie Jednym z kryzysów, z jakimi mogą mierzyć się firmy, jest zmiana przepisów prawa. Gdy wprowadzane są nowe regulacje lub modyfikowane istniejące ustawy, organizacje muszą się do nich dostosować. Dotyczy to zarówno firm, które muszą działać zgodnie z literą prawa, jak i tych, które wytwarzają produkty odzwierciedlające nowe regulacje. Jeśli zmiany są sporadyczne, organizacja zazwyczaj jest w stanie odpowiednio nimi zarządzić. Problem pojawia się, gdy tempo zmian przyspiesza i przedsiębiorstwo działa w coraz większej niepewności. Bardzo często ostateczna wersja przepisów pojawia się tuż przed terminem ich wejścia w życie, co stawia zespoły przed ogromnym wyzwaniem – które muszą w krótkim czasie zaimplementować zmiany i dostosować swoje produkty oraz procesy. Często na szkoleniach czy podczas współpracy z firmami słyszymy, że trzy czwarte pracy w ostatnim roku były oparte na zmianach w prawie. Rzeczywiście, istnieją branże, firmy i produkty, które szczególnie odczuwają częste zmiany legislacyjne. Regulacje potrafią zmieniać się dynamicznie, często niemal na ostatnią chwilę. Bez wnikania w przyczyny takiego stanu rzeczy, faktem jest, że firmy muszą się do tych zmian dostosować. Czasem może się wydawać, że to drobna zmiana – na przykład zmiana jednego paragrafu w przepisach – ale w rzeczywistości może ona generować ogromne konsekwencje technologiczne i organizacyjne. W coraz bardziej cyfrowym świecie zmiany mogą wymagać modyfikacji wielu systemów, na przykład odnalezienia i aktualizacji wszystkich miejsc, w których przetwarzane są dane osobowe, albo całkowitej przebudowy algorytmów obliczających przedawnienie wierzytelności. W klasycznym, projektowym podejściu zarządzanie takimi zmianami może być bardzo trudne, a nawet w podejściu zwinnym wymaga odpowiedniego podejścia. Wejście silnego gracza na rynek Jednym z przykładów kryzysu jest wejście znaczącego nowego gracza na rynek, na którym obecnie działamy. Może się wydawać, że mamy wszystko pod kontrolą, dobrze znamy specyfikę branży i jesteśmy w niej mocno osadzeni. Jednak w dzisiejszych czasach może dojść do sytuacji, w której jedna z dużych firm – Apple, Facebook, Google lub inna globalna marka – zdecyduje się na stworzenie produktu, który z naszej perspektywy nagle staje się konkurencją. Przy możliwościach finansowych i promocyjnych tak dużych firm może się okazać, że nowy produkt szybko zdobywa rynek, a my nie zdążyliśmy się na to przygotować. Czas na reakcję jest wtedy mocno ograniczony, a firmy, które nie są w stanie dynamicznie dostosować swojej strategii, mogą znaleźć się w bardzo trudnej sytuacji. Z takim scenariuszem mieliśmy do czynienia osobiście. W jednej z firm, w której kiedyś pracowaliśmy, pojawiło się realne zagrożenie wejścia globalnego gracza na polski rynek. Już proste kalkulacje pokazywały, jak poważna była sytuacja – według krążących informacji nowy konkurent miał się pojawić w ciągu roku, podczas gdy nasze projekty trwały co najmniej dziewięć miesięcy. Oznaczało to, że już teraz było za późno na skuteczną reakcję. Gdybyśmy chcieli zdążyć z odpowiedzią na konkurencję, musielibyśmy natychmiast porzucić wszystko i skupić się na projektach wyprzedzających. Jednak nawet gdybyśmy pierwszego dnia po debiucie nowego gracza wiedzieli, co należy zrobić, to i tak przez kolejne dziewięć miesięcy dopiero realizowalibyśmy nasze plany. W tym czasie konkurencja mogłaby przejąć znaczącą część rynku – a w najgorszym przypadku całkowicie nas z niego wypchnąć. Taki scenariusz nie jest rzadkością. Wiele firm orientuje się zbyt późno, że ich pozycja jest zagrożona. A nawet jeśli zdają sobie z tego sprawę, ich reakcja jest zbyt wolna, by skutecznie się obronić. Nieprzewidywalne wydarzenia losowe Kolejnym typem kryzysu, z którym możemy się spotkać, są nieprzewidywalne wydarzenia losowe, które mają wpływ na gospodarkę globalną. Mogą to być bardzo różne sytuacje – na przykład wybuch wulkanu, który blokuje ruch lotniczy, tsunami niszczące fabryki produkujące kluczowe komponenty sprzętowe, czy chociażby ostatnie wydarzenia zwi

Czym jest odpowiedzialność zespołu za produkt i dlaczego jest bardzo ważna? Co zrobić, aby zbudować odpowiedzialność za produkt w naszym zespole – poznaj 6 rad, które Ci w tym pomogą. Chcesz zbudować lub wzmocnić odpowiedzialność za produkt w swoim zespole? Dowiedz się jak do tego podejść i na co zwrócić uwagę, aby wspólnie z zespołem tworzyć wartościowe z punktu widzenia użytkownika i biznesu produkty.  Spis treści Czym jest odpowiedzialność za produkt?Dlaczego warto budować odpowiedzialność za produkt w zespole?6 porad jak wzmacniać odpowiedzialność zespołu za produkt📄Transkrypcja podastu „Wzmacnianie odpowiedzialności zespołu za produkt” Z kwestią wzmacniania odpowiedzialności zespołu za produkt bardzo często spotykamy się w naszej pracy. Klienci szukają wskazówek i sposobów, aby ta odpowiedzialność rosła, stąd też dziś podzielimy się z Tobą kilkoma radami, które naszym zdaniem warto zastosować. Nasze porady są dosyć uniwersalne i mogą one być pomocne zarówno dla Scrum Mastera, jak i Product Ownera, czy też członka zespołu lub managera. Czym jest odpowiedzialność za produkt? Najprościej to przedstawić posługując się negatywnymi przykładami zespołów lub pojedynczych osób, które nie zważają na to, co i po co, coś robią, wykonują po prostu swoje zadania, ale bez zaangażowania i zrozumienia, co jest realnie potrzebne. Mogą one nawet bardzo dobrze wykonywać swoją pracę, jednak brakuje tego poczucia odpowiedzialności i zaangażowania. Odpowiedzialność za produkt często jest potrzebna, gdy kreowane są zupełnie nowe rozwiązania lub gdy produkt jest przebudowywany, a bywa, że w toku dyskusji pojawia się problem, że zespół albo nie rozumie, po co coś robi, albo nie rozumie klienta.  Dobrym przykładem braku odpowiedzialności za produkt jest sytuacja, w której Zespół Deweloperski stworzy kawałek produktu, jednak to rozwiązanie nie do końca odpowiada na potrzeby, mimo że technicznie trudno mu cokolwiek zarzucić. I jeśli wówczas w zespole słychać głosy, że wszystko jest zrobione, jak to było zdefiniowane, to łatwo tu rozpoznać ten brak odpowiedzialności za produkt.  Dlaczego warto budować odpowiedzialność za produkt w zespole? Przede wszystkim w zespole, w którym jest odpowiedzialność za produkt i faktycznie dba się o to, aby rozwiązywać problemy użytkowników, to pilnowanie jakości produktu nie spoczywa na barkach jednej osoby. Ponadto, w takim zespole, który rozumie, po co coś robi i jakie problemy rozwiązuje, pojawiają się często trafne, kreatywne pomysły, które przychodzą od różnych osób w zespole. Jednocześnie inspirują one do kolejnych kreatywnych rozwiązań problemów, które mogą być często dużo lepsze, niż mogliśmy zakładać na początku pracy. To daje też dużo satysfakcji, która jeszcze bardziej angażuje w projekt i motywuje do dalszego dbania o wartość tworzonego produktu. Gdy odpowiedzialność za produkt jest rozłożona na cały zespół, to jakość produktu może być potencjalnie wyższa. Przykładowo zespół wyprodukował produkt zgodnie z założeniami, działał on bez zarzutu, jednak widzi, że to nie jest dobre rozwiązanie i nie można go dać użytkownikom. Czyli nie ma tu myślenia: zrobić zgodnie z makietą i oddać, tylko faktycznie zastanowić się, czy nie lepiej dołożyć więcej pracy i zaproponować lepsze rozwiązanie. 6 porad jak wzmacniać odpowiedzialność zespołu za produkt 1. Zrozum i zdefiniuj produktZrozumienie i właściwa definicja produktu jest to krokiem koniecznym do tego, aby zespół był w stanie połączyć codzienne działania (często bardzo techniczne i niskopoziomowe) z ostatecznym celem, który chcemy osiągnąć.Ta definicja musi klarownie mówić, czym produkt jest dla nas, jakie ma cechy, jaki jest zakres tego produktu. Ważne jest też pamiętanie o oczekiwanym rezultacie, gdyż definiując tylko punkty i funkcjonalności do zrealizowania, może powodować, że zespół jest traktowany jako taka “fabryka feature’ów” i zatraci on poczucie, że odpowiada za produkt. Pamiętanie o celu nadrzędnym i tym, do czego produkt ma służyć, pomaga też uniknąć ryzyka zawężenia tej definicji tylko do konkretnego rozwiązania IT – np. aplikacji czy intranetu, zapominając zupełnie o tym, że to rozwiązanie czemuś służy, ma pomagać realizować jakiś cel biznesowy, ma służyć klientowi. Taka redefinicja produktu i spojrzenie poza ramy techniczne, może bardzo rozszerzyć sposób postrzegania zespołu. Przykładowo zespół postrzegany jako zespół intranetowy, bo zajmuje się on intranetem, zamienia się w zespół, który zapewnia lepszą propagację informacji w firmie. To z kolei może pokazać, że w zespole mamy braki kompetencyjne, a dodatkowo zadamy sobie pytanie, czy dotychczas rozwijane rozwiązania, faktycznie rozwiązują ten problem, który sobie zdefiniowaliśmy na bardziej ogólnym poziomie. Opisując to na przykładzie z naszej pracy, zespół zajmujący się komunikacją produktu na początku definiował swoją rolę, jako zespół, który po prostu raz w tygodniu nadaje komunikaty do całej firmy na temat tego, co się zmienia w naszej o

Jakie drogi prowadzą do zostania Scrum Masterem? Co zrobić, jeśli nasza firma nie wie, co to zwinność albo jeśli akurat w naszym zespole nie funkcjonuje Scrum? Poznaj sprawdzone scenariusze i inspirujące historie, dzięki którym dowiesz się, jak zostać Scrum Masterem. Zobacz wersję wideo Dodatkowe materiały Jak się rozwijać w roli Scrum Mastera? 📄Transkrypcja podcastu „Jak zostać Scrum Masterem” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Jacek: W dzisiejszym odcinku porozmawiamy o tym, jak zostać Scrum Masterem. Bardzo często dostajemy to pytanie od osób, które nie pełnią tej roli aktualnie i nie pełniły tej roli w przeszłości i zastanawiają się, w jaki sposób albo… co trzeba zrobić, żeby w taką rolę Scrum Mastera wejść. Kuba: Ponieważ my też kiedyś zaczynaliśmy, to chcemy opowiedzieć, jakie scenariusze tutaj przychodzą nam do głowy, bo to na pewno nie będzie odcinek z gotową stuprocentowo skuteczną receptą. Sami zaczynaliśmy, a później też wielu osobom pomogliśmy zostać Scrum Masterem po raz pierwszy, natomiast odcinek nie będzie o tym, jak się rozwijać. Jacek: Tak, bardzo precyzyjnie pokryliśmy temat, jak rozwijać się jako Scrum Master w odcinku drugim, do którego Cię, słuchaczu, odsyłamy i tam bardzo konkretnie wskazujemy na to, co można zrobić, żeby stać się lepszym Scrum Masterem i żeby wejść na ścieżkę rozwoju, natomiast dzisiaj chcielibyśmy się podzielić z Tobą bardzo konkretnymi strategiami, które przeprowadzą Cię z punktu, w którym nie funkcjonujesz, nie pracujesz jako Scrum Master do momentu, w którym takim Scrum Masterem będziesz miał lub miała szansę zostać. Kuba: I w ramach odcinka przejdziemy przez takie trzy typowe scenariusze z punktu startowego, z którego się rozpoczyna tą drogę, by zostać Scrum Masterem, a cały odcinek podsumujemy naszymi historiami osobistymi, bo akurat obaj mamy historię, która się trochę wymyka tym takim najprostszym schematom, które nam przychodzą do głowy jako najbardziej popularne. I te najpopularniejsze scenariusze, które będą po kolei częścią odcinka, to jest, że:– „W moim zespole jest Scrum, ale ja Scrum Masterem nie jestem”;– „W mojej firmie jest Scrum, ale ja akurat nie jestem w żadnym Zespole Scrumowym, więc jest mi trochę trudniej, trochę dalej do Zespołu Scrumowego”; – Najtrudniejszy przypadek: „Nie ma Scruma w mojej firmie, jestem w takiej roli albo w takiej w ogóle firmie, że tego Scruma nie ma, a mimo wszystko z jakiegoś powodu czuję lub już wiem, że Scrum i Scrum Master to jest coś dla mnie”. Jacek: Czyli pochylimy się nad tym pierwszym wariantem, w którym zwinność czy konkretnie framework scrumowy to jest metoda, której używamy pracując w zespole, natomiast jesteśmy w roli, która nie jest rolą scrum masterską, czyli na przykład: to może być tester oprogramowania, to może być programista, to może być analityk, to może być osoba, która zajmuje się marketingiem, możesz być osobą, która zajmuje się sprzedażą. Zakładamy, że w zespole jest Scrum Master, natomiast Ty tym Scrum Masterem konkretnie nie jesteś. No i co można zrobić, będąc w takiej pozycji, żeby takim Scrum Masterem zostać? Co byś, Kuba, doradził w pierwszej kolejności? Kuba: Tutaj powiedziałbym ogólnie: przede wszystkim pokazać aktywność i chęć w realizowaniu się w tej roli, więc po prostu całemu zespołowi dać sygnał, że „Chcę tego spróbować”, dać sygnał na przykład na Retrospektywie, dać sygnał Scrum Masterowi, który jest obecnie, że „chętnie spróbuję tej roli”. I różnie sytuacja może się rozwinąć. Taki bardzo prosty scenariusz, to jest propozycja: „Słuchajcie, chcę poprowadzić najbliższą Retrospektywę Sprintu, dajcie mi spróbować, chcę zrobić ją po swojemu, trochę inaczej niż do tej pory, chcę poczuć, jak to jest”. Jacek: Innym przykładem, jak tak na próbę wejść w tą rolę, to jest na przykład wzięcie na siebie jakiegoś problemu zespołu, który trzeba rozwiązać, no i zapewnienie, obiecanie, wyrażenie woli, że „Słuchajcie, zajmę się tym problemem, bo interesuje mnie rola Scrum Mastera” i na próbę taki jakiś temat staramy się rozwiązać.  Kuba: Fajne historie też takich Scrum Masterów, którzy się w zespole pojawili, znaczy, zawsze byli, tylko w innej roli, widzę u osób, które dosyć krytycznie podchodzą do sytuacji czy sposobu pracy danego zespołu, czyli osoby, które są bardzo aktywne na Retrospektywie, zadają pytania, wrzucają jakieś kontrpropozycje czy w ogóle dostrzegają, że coś jest nie tak i starają się coś z tym zrobić, no i to są osoby, które mogą być bardzo dobrym kandydatem na Scrum Mastera, bo mają wyczulone oko, a z perspektywy całego zespołu to są osoby, które pokazują wszystkim pozostałym, że to jest osoba, której powierzylibyśmy tą funkcję, zwłaszcza w tym aspekcie ciągłego doskonalenia, pomagania całemu zespołowi się doskonalić – bo to jest osoba, która pokazuje na przykładach, że dostrzega niedoskonałości zespołu.

Czym jest Przegląd Sprintu? Jak powinien wyglądać, a jak nie? Poznaj 6 rad dotyczących organizacji porządnego Przeglądu Sprintu i dowiedz się, jakich błędów unikać oraz na co zwrócić uwagę, by Przeglądy przebiegały sprawnie i przynosiły możliwe najlepsze rezultaty. Czym jest Przegląd Sprintu? Przegląd Sprintu najprościej rzecz ujmując, jest wydarzeniem, podczas którego dokonujemy inspekcji Przyrostu Produktu oraz dostosowujemy działania do otrzymanych wyników. Przegląd Sprintu jest bardzo dokładnie opisany w “Przewodniku po Scrumie” i zachęcamy do zaglądnięcia do niego, gdyż zawiera on konkretną listę elementów, które powinny wchodzić w zakres tego wydarzenia Scrumowego. Oczywiście, jest to lista poglądowa i należy ją traktować jako inspirację pomagającą obrać kierunek działania dopasowanego do realiów zespołu lub organizacji.  Spis treści Czym jest Przegląd Sprintu?Przegląd Sprintu – najczęstsze błędyJak zorganizować porządny Przegląd Sprintu? 📄Transkrypcja podcastu „Porządny Przegląd Sprintu” O tym, jak realizować Porządny Sprint rozmawialiśmy w 20. odcinku podcastu, a tu tylko przypomnimy, że taką inspekcję produktu można, a nawet warto przeprowadzać także w trakcie Sprintu, dzięki czemu sam Przegląd Sprintu będzie tylko formalnością zapewniającą wszystkich, że produkt podlega inspekcji. Nim przejdziemy do tego, jak realizować porządny Przegląd Sprintu, to bardzo mocno zachęcamy Was do otwartości na przyznanie się do błędów lub do niewiedzy, a także pozwolenia sobie na proszenie o pomoc. Nie traktujcie Przeglądu Sprintu tylko jako okazji do chwalenia się i pokazywania tylko tego, co wyszło. Dbajcie o budowanie szczerej komunikacji opartej na zaufaniu, komunikacji zarówno między członkami zespołu, jak i zespołem i Interesariuszami. Będziemy o tym pisać jeszcze w dalszej części artykułu, jednak ponieważ naszym zdaniem jest to bardzo istotna rzecz, to chcieliśmy to poruszyć na samym początku. Przegląd Sprintu – najczęstsze błędy 1. Brak Przeglądu Sprintu  Być może brzmi to dla Ciebie nieprawdopodobnie, ale my wciąż spotykamy się z sytuacjami, gdzie Przegląd Sprintu jest pomijany. Czasem nie ma go wcale, a czasem jest organizowany tylko co któryś Sprint. Po prostu zespół nie dokonuje regularnej inspekcji tworzonego produktu.  2. Na Przeglądzie Sprintu brak jest Interesariuszy Kolejny błąd to przeprowadzanie Przeglądu Sprintu tylko w ramach własnego zespołu, bez obecności żadnego z Interesariuszy. Pokazujemy sobie rezultaty pracy, które tak naprawdę każdy z zespołu powinien i tak znać je już poprzez sam fakt współpracowania ze sobą.  W ten sposób pozbawiamy się ciekawych wniosków i przemyśleń osób, które nie siedzą tak mocno w produkcie, jak zespół i które mają mocniejsze spojrzenie biznesowe, a nie tylko technologiczne. 3. Przyrost nie jest prezentowany Nawet jeśli Przeglądy Sprintów odbywają się regularnie i biorą w nich udział osoby spoza zespołu, jednak nie prezentujemy im przyrostu, czyli kolejnej wersji działającego kawałka produktu, będącej efektem ostatniego Sprintu. To z kolei zwykle nie inicjuje żadnych dyskusji i przybiera formę jednostronnego pokazu, tym gorzej, jeśli w postaci listy wykonanych tasków. 4. Brak rozmowy o dalszych planach Przegląd Sprintu to nie tylko patrzenie wstecz, ale także jest w nim miejsce do rozmowy o tym, co jest obecnie w Backlogu produktu i zaplanowania kolejnych kroków. Jest to istotne z tego względu, że w wydarzeniu biorą udział również Interesariusze, którzy mogą wnieść wiele ciekawych spostrzeżeń i informacji, które być może jeszcze nie dotarły do Zespołu deweloperskiego. Jak zorganizować porządny Przegląd Sprintu?  Przedstawiliśmy Wam najczęstsze błędy, z którymi się spotykamy podczas naszej pracy z różnymi organizacjami i zespołami. Teraz podpowiemy Ci, jak zorganizować porządny Przegląd Sprintu, aby przynosił faktyczną wartość. 1. Zawsze pokazuj Przyrost Przegląd jest okazją do inspekcji Przyrostu Produktu, ale żeby móc tego dokonać, to najpierw musimy go zaprezentować. Ta porada może brzmieć dla Ciebie banalnie, jednak pamiętaj, że są sytuacje, gdy pokazanie efektów naszej pracy może wymagać odwagi, jeśli nie są one satysfakcjonujące i coś nam nie wyszło. Przecież zdarza się tak, że nie udało się nam czegoś dokończyć, czasem coś nie działa, a czasem po prostu tego Przyrostu nie ma. Jednak nie należy uciekać od tego elementu przeglądu, tylko porozmawiać o przyczynach takiego stanu rzeczy: jakie były przeszkody, czy problemy. Pamiętaj też, że poprzez pokazanie Przyrostu, nie mamy na myśli pokazania listy odhaczonych zadań w narzędziu do zarządzania projektami (np. w Jirze).  Jeśli nie macie możliwości pokazania kawałka produktu czy kodu, to warto ustalić z Interesariuszami, co tym Przyrostem ma być dla nas wszystkich, aby móc potem je jakoś interpretować. Taka sytuacja może się pojawić, zwłaszcza gdy naszym produktem jest np. usługa lub jakiś proces czy wydarzenie. W takich przypadkach Przyrostem może być

Jaka przyszłość czeka podejście zwinne? Jakich trendów można się spodziewać w Agile’u? Czy znajdą się jakieś alternatywy dla obecnych rozwiązań i czy będą one dobre dla środowisk pracujących zwinnie? O tym w 28. odcinku podcastu. Zobacz wersję wideo Dodatkowe materiały, które wspominamy w nagraniu: Jak się rozwijać w roli Scrum Mastera Certyfikaty w Scrumie 📄 Transkrypcja podcastu „7 trendów w Agile na przyszłość” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Jacek: W dzisiejszym odcinku opowiemy o siedmiu trendach w Agile’u na przyszłość, które wraz z Kubą przygotowaliśmy. Są to rzeczy, które uważamy, że najprawdopodobniej się zadzieją. Część z tych rzeczy jest już dosyć dobrze obserwowalna, pewne rzeczy to są bardziej nasze takie wyobrażenia czy przewidywania na bazie tego, czego doświadczamy na co dzień, wspierając firmy w poprawianiu tego, jak pracują. Kuba: Inspiracją do tego, żeby nagrać ten odcinek był przełom roku, bo nagrywamy go na samym początku stycznia, siedzimy sobie z Jackiem w samochodzie na skraju Wielkopolskiego Parku Narodowego i pomyśleliśmy, że możemy się podzielić trochę historiami o tym, jak widzimy rozwój sytuacji w świecie zwinności, natomiast czas pokaże, sami jesteśmy zaciekawieni, jak odbierzesz ten odcinek, jeśli słuchasz go później, może nawet parę lat później niż w momencie, gdy go nagrywamy. Jacek: Pierwszym z trendów, co do którego z Kubą się zgodziliśmy, to jest trend, w którym podejście zwinne wychodzi poza IT. I obserwujemy ten trend dosyć wyraźnie – tak właściwie można powiedzieć, „na własnej skórze”, ponieważ coraz większa liczba firm, które nie są firmami IT, czyli na przykład nie produkują własnych produktów cyfrowych, odzywa się do nas z pytaniami, z prośbami o wsparcie, no i bardzo ten trend jest dla nas wyraźny. Moje doświadczenie, o którym już wspominałem w podcaście, no to chociażby moje ostatnie dwa lata pracy, to są w większości firmy, które po prostu nie są firmami IT, natomiast są bardzo zainteresowane tym, czym jest zwinność, czy mogą wykorzystać podejście zwinne w swojej branży, no i – to najważniejsze pytanie – jak to zrobić w praktyce? Kuba: Niedawno byłem na społeczności zwinnej, gdzie zaproponowałem temat opowiedzenia trochę właśnie o tym, jakie są moje doświadczenia wykorzystania podejścia zwinnego w świecie niezwiązanym z IT i byłem w ciężkim szoku, jak kolega, który – jeśli słucha tego podcastu, to go pozdrawiam – powiedział, że on też tak praktykuje zwinność i jest z firmy, która produkuje dźwigi budowlane. Czyli zupełnie inne branże, zupełnie odległe od tego świata cyfrowego, odnajdują coś w podejściu zwinnym. Odnajdują też potrzebę w sobie do tego, żeby to podejście zwinne zastosować. I to jest ciekawy trend – on narasta. Z naszej perspektywy – jako konsultanci, trenerzy to widzimy w postaci zapytań. Widzę to w społecznościach w postaci pojawiających się osób z firm naprawdę dalekich od IT czy firm korzystających ze zwinności. Widzę to też na przykład w ofertach czy ogłoszeniach o pracę – najbardziej ciekawą dla mnie była oferta na Scrum Mastera do firmy, która produkuje okna. Są branże, które nie mają nic wspólnego ze światem IT, a mogą potrzebować podejścia zwinnego, czy konkretnych frameworków czy chociaż takiego sposobu myślenia czy sposobu wprowadzenia prac rozwojowych – cokolwiek dana firma rozwija. Jacek: Do tego, co mówisz, to bym dodał jeszcze dostępne w Internecie case’y firm, które wykorzystywały podejście zwinne dla pewnych fragmentów swojej działalności. Nie zawsze to były firmy typowo nie-IT, natomiast często to były case’y czy jak użyć podejścia zwinnego w marketingu, czy jak użyć podejścia zwinnego w sprzedaży, czy jak użyć podejścia zwinnego w działach HR. Natomiast zgodziliśmy się z Kubą, że nie ma takiego bezdyskusyjnego case’a użycia podejścia zwinnego poza IT na rynku, które byłoby takim, myślę, dowodem dla osób, które się jeszcze wahają, że warto spróbować. Kuba: Dowodem albo takim mocnym sygnałem rozpoczęcia mody, czyli my to mówimy, że to już jest trend, ale pewnie jeszcze nie jest moda, natomiast jeśli obserwujemy tą modę w innych obszarach, ja bym wyróżnił modę w ogóle na podejście zwinne i tutaj czujemy, że to już parę ładnych lat trwa. Była moda też w poszczególnych branżach – na przykład w którymś momencie moda na branżę ubezpieczeniową, moda na branżę bankową – często widać wyraźnie, że pojawia się jeden wyrazisty przykład – tu pozwolimy sobie użyć przykładu PZU, które w którymś momencie było dosyć aktywne i chętnie propagowało informacje o swoim projekcie zwinnym – i nagle się okazało, że wszyscy w branży też chcą tego spróbować. Podobnie teraz można już od paru lat widzieć to samo w bankowości. To samo czeka świat Agile’a poza IT i ja póki co nie znam takiego bardzo mocnego case’a, bardzo mocnego brandu czy mocnej marki jakiejś fajnej, duż

Dlaczego warto powołać zespół pracujący zwinnie w niepełnym wymiarze czasowym, jakich zagrożeń unikać podczas jego działania i jak wyciągnąć najwięcej korzyści z jego istnienia? Rozmowa w formie wideo Dodatkowe materiały Członek zespołu w niepełnym wymiarze czasowym 📄Transkrypcja podcastu „Zespół w niepełnym wymiarze czasowym” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Kuba: Poprzedni odcinek podcastu poświęciliśmy przypadkowi, gdy członek zespołu nie jest w pełnym wymiarze czasowym. Specjalnie na kolejny odcinek, czyli ten, którego zaczynasz właśnie teraz słuchać, zostawiliśmy sobie wątek, gdy to cały zespół jest w niepełnym wymiarze czasowym. Opowiemy w tym odcinku, jakie widzimy plusy takich sytuacji. Opowiemy też o minusach lub zagrożeniach i podpowiemy trochę praktyk, jak się do tego tematu zabrać. Jacek: Na omówienie tego tematu zdecydowaliśmy się z tego powodu, że pracując jako konsultanci z różnymi firmami, bardzo często spotykamy się z taką sytuacją, gdy firmy chcą skorzystać z podejścia zwinnego, natomiast nie do końca wiedzą, jak do tego podejść. I w szczególności chciałyby zrobić to w taki „bezpieczny” sposób. I mamy z Kubą całkiem sporo doświadczeń we wspieraniu tego typu zespołów – czyli zespołów zwinnych, które nie pracują w pełnym wymiarze czasu i tymi doświadczeniami chcielibyśmy się dzisiaj z Tobą podzielić. Kuba: I na pewno jest tak, że jeśli tylko jest możliwość pracy z zespołem, który jest dedykowany czasowo albo ma tego czasu bardzo dużo na pracę razem ze sobą, to zdecydowanie polecamy ten scenariusz, ale czasami nie jest to możliwe lub nie jest to możliwe w danym momencie rozwoju firmy. Bo jeśli patrzymy z perspektywy plusów takiej pracy, to właśnie najbardziej powtarzalny scenariusz, jaki nam przychodzi do głowy, to ten przypadek, w którym firma dopiero zaczyna pracę w sposób zwinny, eksperymentuje z tym podejściem lub zna je w świecie IT, zna je w świecie rozwoju swoich systemów IT i chce je przenieść poza ten świat IT, na przykład do projektów biznesowych, do projektów marketingowych czy HR-owych. I wtedy ten taki scenariusz: „Dobrze, to zróbmy super dedykowany na 100% zespół projektowy” nie jest albo możliwy, albo – bardziej bym powiedział – raczej nie jest wyobrażalny dla osób, które o tym decydują, no i scenariusz, w którym zaczynamy pracować na przykład na pół etatu w projekcie zorganizowanym w postać zespołu zwinnego, wydaje się być prostszym eksperymentem, więc pierwszy plus, jaki byśmy chcieli wymienić, pracy w niepełnym wymiarze czasowym, że to jest chociaż w jakimś wymiarze czasowym praca w sposób zwinny, jest to eksplorowanie różnych nowych sposobów pracy dla tej organizacji czy dla tego typu przedsięwzięć w tej firmie i ten sposób nie wymaga radykalnych zmian – dedykowane zespoły na cały czas, na full time tak zwany, prawdopodobnie wymagają o wiele głębszych reorganizacji, być może przesunięć zadań między osobami. Coś, co jest relatywnie prostsze do wykonania w przypadku zespołu niededykowanego czasowo. Może być to też bezpieczny mały krok. Nie musimy się od razu zobowiązać do bardzo dużych zmian, zadeklarować, że te duże zmiany nastąpią w trwały sposób. Możemy ten eksperyment zrobić w postaci bezpieczniejszego, prostszego, mniejszego kroku. Jacek: Kolejnym argumentem za tym, żeby taki zespół funkcjonujący w niepełnym wymiarze czasu powołać, jest to, że można poprzez ten eksperyment, o którym przed chwilą powiedziałeś, uzyskać całkiem sensowne i, powiedziałbym, lepsze rezultaty. Z czego to wynika? Wynika to z tego, że jeżeli taki zespół zwinny konstruujemy we właściwy sposób, no to zwykle zaczynamy gdzieś w okolicy zastanowienia się, jaki w ogóle jest cel pracy tego zespołu. Co stoi za tym, że taki konkretny zespół chcemy powołać? Jaką mamy wizję? Albo jaki jest problem, z którym się mierzymy i czego byśmy się spodziewali po pracy tego zespołu? Zwykle też powoływany jest czy wyłania się jakaś osoba w roli lidera, która zwykle też potrafi być – w takim pozytywnym scenariuszu – pewnym takim motorem napędowym czy osobą, za którą ludzie podążają. No i jeszcze jeden taki przykładowy aspekt, dlaczego te rezultaty mogą być lepsze – no bo jednak wyciągamy osoby z ich codziennej pracy i umieszczamy te osoby w kontekście zespołu. Czyli tak jak przed chwilą powiedziałem, też w kontekście jakiegoś problemu, jakiegoś celu, jakiegoś produktu. I pomimo iż te osoby nie są dedykowane na pełen okres czasu, obserwuję to, że jednak takie pozytywne zjawisko skupienia występuje. Czyli pomimo iż nie mam pełnych ośmiu godzin na to, żeby pracować nad tym konkretnym problemem, no to mimo wszystko, jak już jestem zespołem, to zwykle występuje coś takiego, że ludzie chcą płynąć do brzegu, chcą osiągać rezultaty, no i ta formuła bycia w jakimś konkretnym, nazwijmy to może nawet, „wirtualnym zespole”, zaczyna nabierać sensu. Kuba: Następnym plu

Zasady współpracy z członkiem zespołu pracującym w niepełnym wymiarze czasu – co zrobić, by przebiegała ona sprawnie i efektywnie? Jak zadbać o zdrową atmosferę w zespole i skuteczność działań? O tym w 26. odcinku podcastu Porządny Agile. Zobacz wersję wideo Dodatkowe materiały Niezaangażowany członek zespołu Porządne Planowanie Sprintu Książka „The Principles of Product Development Flow: Second Generation Lean Product Development” Donalda Reinertsena 📄 Transkrypcja podcastu „Członek zespołu w niepełnym wymiarze czasowym” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Jacek: W dzisiejszym odcinku porozmawiamy o sytuacji, w której członek zespołu jest dostępny, ale w niepełnym wymiarze czasowym, czyli jest to sytuacja, w której mamy zespół złożony z osób o różnych kompetencjach, natomiast część zespołu jest dostępna na 100% i realizuje tylko rzeczy związane z konkretną inicjatywą, dla której powołany został zespół, a część osób występuje w niepełnym wymiarze, np. 50%, 20%, jeden dzień w tygodniu. Kuba: I mamy na myśli takie przykłady, jak  zespoły zwinne pracujące nad jakimś problemem biznesowym, które składają się z różnych specjalistów dedykowanych do projektu czy do inicjatywy, ale np. wspiera ten projekt – i to bardzo konkretnie – przedstawiciel zespołu operacji biznesowych, który ma duży wkład, dużo wnosi, dużo pomysłów, ma też jakiś element do zrealizowania w projekcie, ale z racji tego, że jest to osoba z jakiegoś zespołu operacyjnego, nie jest dedykowana na 100%, jest dostępna tylko w wybrane godziny lub w wybranym okienku czasowym. Jacek: Przykład takiej sytuacji – wyobraźmy sobie zespół, który pracuje nad produktem, mamy tam reprezentantów produktu, mamy tam reprezentantów działu marketingu czy osoby o kompetencjach marketingowych, mamy osoby o kompetencjach sprzedażowych, które sprzedają ten produkt i te osoby są zaangażowane w rozwój produktu na 100%, ale przychodzi moment, kiedy potrzebują np. kompetencji badacza, który pomoże im zrozumieć użytkowników, którzy korzystają z produktu, przeprowadzi jakieś ankiety, jakieś badania. No i ta kompetencja nie jest dostępna w tym zespole na 100%, ta osoba (tego badacza) wspiera zespół, no, ale nie można powiedzieć, że w pełnym wymiarze czasowym. Kuba: I bardzo świadomie te dwa pierwsze przykłady użyliśmy z realiów zespołów zwinnych, ze środowiska nie-IT, ale taki przykład trzeci, który dobrze oddaje ten przykład tematu naszego odcinka, to wsparcie grafika. Zarówno zespoły IT, jak i zespoły nie-IT od czasu do czasu potrzebują wsparcia grafika, ale przynajmniej niektóre produkty, niektóre projekty, niektóre zespoły mogą tego grafika potrzebować tylko w niepełnym wymiarze czasowym. Nazwę to tak, w cudzysłowie – są w stanie go „wyżywić”, czyli ta kompetencja grafika jest potrzebna wyłącznie na jakiś procent czasu, no i ten grafik współpracuje z tym zespołem na niepełnym wymiarze czasowym. Być może współpracuje z kilkoma zespołami w tak niepełnym wymiarze czasowym.  I dlaczego o tym w ogóle odcinek? Bo coś, z czym się w praktyce spotykamy to to, że ta sytuacja ma swoje plusy – o nich jeszcze trochę powiemy, ale przede wszystkim najczęściej w zespołach one kojarzą się z niekorzystnymi zjawiskami. Jacek: Tak, przede wszystkim z perspektywy członków zespołu posiadanie takiej osoby, która jest w zespole w niepełnym wymiarze tworzy dla zespołu zależność zewnętrzną, którą trzeba w jakiś sposób zarządzić. I takim najczęściej powtarzanym problemem, z którym się spotykam, pracując z organizacjami, jest to, że taka osoba zewnętrzna w jakiś sposób – mówiąc potocznie – rozwala plany, czyli zespół chciałby móc mieć planowanie pod swoją kontrolą i wpływ na to, kiedy pewne rzeczy się zadzieją, no i na te rzeczy – na kompetencje, które są w ich ramach – mają wpływ. Natomiast kompetencje, które są dochodzące, kompetencje, które są dostępne w niepełnym wymiarze czasowym – te osoby już mogą powodować pewnego rodzaju problemy, na zasadzie: „Umówiliśmy się, że do pewnego, do konkretnego dnia dostarczam jakieś półprodukty, jakieś rzeczy, no i te rzeczy są niedostarczone”. Kuba: I podobny temat problematyczny do tego, co, Jacek, powiedziałeś przed chwilą to to takie niepełne zaangażowanie. Mamy kogoś, kto jest bardzo „w środku” projektu, bardzo mocno wewnątrz zespołu, w pełni oddany – i fizycznie dosłownie widać, że mamy też kogoś, kto albo jest trochę dalej od nas, jest rzadziej z nami – to wszystko powoduje, że nie mamy z tą osobą takiej relacji i nie możemy na sobie polegać nie tylko z perspektywy planów, ale też nie możemy na sobie polegać z perspektywy takiej… współpracy. Z tą osobą jest po prostu słabszy kontakt – zaczynają się nam rodzić różne pytania, czy różne wątpliwości czy podejrzenia, czy wszyscy jesteśmy tak samo mocno zaangażowani, czy – tak symbolicznie mówiąc &#8211

Co to jest Codzienny Scrum i jak realizować go porządnie? Jak się okazuje, wcale nie jest to tak proste, jak mogłoby się wydawać. Podpowiadamy, na co zwrócić uwagę, by to wydarzenie scrumowe było jak najbardziej efektywny i przynosił korzyści Deweloperom. Spis treści artykułu: Czym jest Codzienny Scrum? Kto uczestniczy w Codziennym Scrumie? Najczęstsze dysfunkcje Codziennego Scruma Porządny Codzienny Scrum: nasze wskazówki Po czym poznać, że Codzienny Scrum odbywa się w prawidłowy sposób? Czym jest Codzienny Scrum?Codzienny Scrum, nazywany również stand-upem czy daily, jest około 15-minutowym spotkaniem Deweloperów, które jak sama nazwa wskazuje, odbywa się każdego dnia. Ma ono na celu synchronizację zespołu oraz zaplanowanie dnia pracy. Oczywiście w przypadku niewielkich i dobrze zgranych zespołu Codzienny Scrum może trwać o wiele krócej, nawet tylko 5 minut. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo. Kto uczestniczy w Codziennym Scrumie? W zależności od podejścia i od firmy, w wydarzeniu tym może uczestniczyć Scrum Master i Product Owner, choć nie jest to obowiązkowe. Nie powinni jednak oni zakłócać przebiegu spotkania, jak to jest zgrabnie ujęte w Przewodniku po Scrumie. Dodatkowo, zwłaszcza w organizacjach z wieloma Zespołami Scrumowymi, na Daily może pojawić się osoba z innego zespołu, żeby zobaczyć, jak to spotkanie wygląda u innych. Oczywiście także i ona nie powinna wpływać na przebieg wydarzenia. Najczęstsze dysfunkcje Codziennego Scruma Tak jak wspomnieliśmy wcześniej, Codzienny Scrum powinien być krótkim, codziennym spotkaniem w ramach porannej rutyny zespołu. Niestety często widzimy, że jego idea nie jest do końca dobrze rozumiana, co prowadzi do popularnych dysfunkcji. Codzienny Scrum jako spotkanie statusowe Codzienny Scrum potrafi przybrać formę klasycznego spotkania statusowego. Oznacza to, że Deweloperzy w sposób automatyczny i bezrefleksyjny „spowiadają” się z tego, co robili wczoraj i czym będą zajmować się dzisiaj. Brakuje faktycznych interakcji, które są fundamentem faktycznego współdziałania w zespole. Codzienny Scrum nie wnoszący nic do funkcjonowania zespołu Jeżeli daily nic nie wnosi do pracy czy funkcjonowania zespołu, nasila się poczucie marnowania czasu Deweloperów. Spotkanie może sprawiać wrażenie bardzo mechanicznego, gdzie trzeba się szybko wypowiedzieć, aby jak najszybciej mieć wolne. Codzienny Scrum jako część rutuału scrumowego Bywa, że daily staje się podobne do kultu cargo. Musi się codziennie odbyć zgodnie ze sztywno ustalonymi krokami, aby móc odhaczyć wykonanie jednej ze składowych Scruma. Dzięki temu będziemy odnosić takie same sukcesy, jak zespoły opisywane w najlepszych case studies. Niestety są to bardzo złudne założenia. Porządny Codzienny Scrum: nasze wskazówki Wymieniliśmy najczęstsze dysfunkcje, jakie pojawiają się w ramach przeprowadzania Codziennego Scruma. Poniżej znajdziesz praktyczne wskazówkami jak zorganizować porządne spotkanie synchronizacyjne dla zespołu. Sprawdzaj, co udało się zrealizować w ramach Celu Sprintu i aktualizuj plan Tak jak Codzienny Scrum nie ma na celu tłumaczenie się z wykonanej poprzedniego dnia pracy, tak też nie jest spotkaniem statusowym. Wykorzystaj ten czas na inspekcję postępu prac i Backlogu Sprintu. Spójrz realnie na to, co zostało wykonane i jak to się ma do prognozy pracy zaplanowanej podczas Planowania Sprintu. Plan pracy zespołu zwykle ulega drobnym zmianom w trakcie trwania Sprintu i Codzienny Scrum jest właściwym spotkaniem, ale zaktualizować plan osiągnięcia zaplanowanego Celu Sprintu. Analizuj z zespołem sposób, w jaki realizujecie Codzienny Scrum Warto znaleźć czas na zastanowienie się z zespołem, czy daily jest porządnie przeprowadzane. Warto przypomnieć sobie wskazówki z Przewodnika po Scrumie lub porozmawiać z innymi zespołami w celu wymiany doświadczeń. Jeżeli struktura organizacyjna na to pozwala, warto podejrzeć jak wyglądają Codzienne Scrumy w innych zespołach lub w innych organizacjach. Po czym poznać, że Codzienny Scrum odbywa się w prawidłowy sposób? Istnieje kilka wskazówek, które pomagają tak przedprowadzić daily, aby przynosiło ono jak najwięcej wartości dla uczestniczących w nim Deweloperów. Oto 5 naistotniejszych porad. wydarzenie toczy się wokół dyskusji na temat progresu pracy w kontekście Celu Sprintu. O samym Celu Sprintu mówiliśmy więcej w 7. odcinku podcastu, natomiast co jest ważne w kontekście Daily, to dobrze określony Cel Sprintu, ułatwia pracę całego zespołu, jak i właśnie prawidłowy przebieg spotkań. Skupienie się bardziej na tym, co się udało zrobić, z pominięciem kontekstu celu, do którego dążymy, pokazuje, że powinniśmy zoptymalizować nasze Daily. W sumie Cel Sprintu jest bardzo dobrym sposobem na moderowanie Codziennego Scruma, zwłaszcza jeśli mamy problemy z zamknięciem się w 15 minutach. Nie mówimy zatem o wszystkich naszych aktywnościach, tylko wybieramy te rzeczy,

Konferencje branżowe – czy warto w nich uczestniczyć? Jakiej mogą dostarczyć nam wartości, jak najlepiej je wykorzystywać i czego nie robić, jeśli rzeczywiście chcemy dobrze spędzić na nich czas – o tym w 24 odcinku podcastu. Zobacz wersję wideo 📄 Transkrypcja podcastu „Jaka jest wartość konferencji?” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Kuba: Dzisiejszy odcinek powstaje z inspiracji naszego udziału w konferencji AgileByExample. Rozmawialiśmy w czasie tej konferencji, też obserwowaliśmy udział różnych osób i doszła do nas taka refleksja, że udział w konferencjach to jest coś, nad czym warto się pochylić. Co mamy na myśli to to, że kilka osób, niezależnie od siebie, w toku całej konferencji – czy to na przerwach, czy również na imprezie wieczornej – pytało nas, jak nam się konferencja podoba, jaka jest dla nas wartość konferencji jako takich i dlaczego w ogóle bierzemy w nich udział. I inspirując się konkretnie przypadkiem AgileByExample chcemy po prostu opowiedzieć trochę o tym, co widzimy wartościowego w konferencjach, dlaczego warto w nich udział wziąć i też może trochę porad na temat tego, jak się do tego nastawić czy też na co zwrócić uwagę, żeby czerpać maksymalną możliwą wartość z takich właśnie konferencji. Jacek: Kiedy myślę o tym, co mi przychodzi pierwsze do głowy, jeśli chodzi o pytanie, dlaczego bywam na konferencjach, to przede wszystkim jestem na konferencjach w poszukiwaniu inspiracji. I te inspiracje generalnie mogą się pojawić na wielu poziomach. Przykładowo – szukam inspiracji, jeśli chodzi o nowe obszary bądź nowe zagadnienia związane ze zwinnością. Wielokrotnie się zdarza, że mądrze wybierając, na którą prezentację się wybiorę – zakładając, że jest kilka ścieżek – powoduje, że trafiam na spikerów, prezentujących treści, które z mojej perspektywy, moich doświadczeń, są nowymi treściami. I to jest okazja, żeby posłuchać o tym, co mówią, poznać nowe narzędzie, poznać nowe podejście albo poznać jakiś alternatywny sposób patrzenie na jakieś konkretne rzeczy. Z drugiej strony patrząc, innym poziomem inspiracji dla mnie jest taki wymiar czysto ludzki, czyli mam szansę zobaczyć w akcji, czyli prezentujących, różne osoby. I te osoby… czasem bywa tak, że na przykład nie przekonają mnie konkretnie tematem – bo na przykład jest to temat, który jest mi bliski i nie wynoszę aż tak dużo na poziomie nowej wiedzy – natomiast sama osoba jest ciekawa albo kiedy zaczynam sobie czytać w Internecie o tej osobie, to natrafiam na inne materiały, które różnią się treścią od tego, co widziałem na konferencji, niemniej na przykład dzięki temu staję czytelnikiem bloga konkretnej osoby. Tak więc ta inspiracja może być zarówno taka, że dostaję od razu merytorycznie gotowe, nazwijmy to, ciekawe treści albo inspiracja na zasadzie: jakaś osoba jest dla mnie inspiracją i dopiero gdzieś tam dalej, po samej konferencji, docieram do ciekawych materiałów. Jakby… Koniec końców oba te źródła inspiracji kończą się tym, że dowiaduję się czegoś nowego. Kuba: Powiedziałeś bardzo ważną rzecz i bardzo trudną – od razu mi się przypomniał taki przypadek, gdzie byłem na konferencji z pewną osobą i konferencja miała dosłownie dwa „tracki” czy dwa „strumienie” prezentacji i bardzo szliśmy na inny – w sensie ja szedłem na jeden track, a druga osoba szła na drugi track i dosłownie za każdym jednym razem (ale to nie było tak, że się umówiliśmy „Ja idę na to, ty idź na to”, tylko po prostu: „Na co idziesz?”, „No ja na to”, „A ja akurat na to drugie”). Jacek: Czyli preferencja… Kuba: Jakby… Za każdym razem wybieraliśmy i za każdym razem tak się wydawało, że wybieraliśmy odwrotnie, no i ja byłem bardzo zadowolony z tej konferencji i z tych kolejnych wystąpień, a tam, no, było dużo pecha w trafianiu na niewłaściwe rzeczy. A może to nie jest pech? Może… Bo powiedziałeś coś takiego: „Wybieram, na co idę”. Jak to robisz? Jacek: Jak to robię? No tak… Pierwszą rzecz, jaką widzę, zazwyczaj ona mi się w pierwszej kolejności rzuca w oczy, to jest, czy znam tego prezentera. No i to może być dla mnie albo sygnał… coś, co mnie zachęca, żeby tam pójść albo wręcz przeciwnie – jak widzę, że prezentuje „X”, no to nie idę, bo na przykład byłem na wcześniejszych prezentacjach i w jakiś sposób mi – że tak powiem bardzo ogólnie – nie podeszły albo po prostu osoba, nie wiem, skupia się w swojej twórczości na omawianiu, czym są Retrospektywy. No, ja… na taki temat akurat na tym etapie rozwoju, jakim jestem, no to po prostu najprawdopodobniej się nie wybiorę. Więc, po pierwsze, patrzę, jak kto prezentuje. Druga rzecz, na jaką patrzę – no to oczywiście jest temat. I tam też jest coś takiego, że dobrze napisany tytuł prezentacji może mnie albo zaciekawić, rzadziej zniechęcić, raczej może być po prostu taki neutralny. No, trzecia

Czy sztywne terminy są zaprzeczeniem Agile’a? Czy można mówić o pracy zwinnej, jeżeli mamy narzuconą końcową datę projektu? Jakie korzyści może przynieść ustalenie deadline’u? O tym w 23. odcinku podcastu Porządny Agile. Zobacz wersję wideo Dodatkowe materiały Książka „Deadline. Zdążyć przed terminem” Toma DeMarco 📄 Transkrypcja podcastu „Praca na termin w Agile” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Jacek: W dzisiejszym odcinku porozmawiamy o deadline’ach w Agile’u, czyli o sytuacji, w której mamy pewne ograniczenie czasowe i tę pracę, którą wykonujemy, musimy na konkretny termin mieć gotową. Kuba: Teza, która gdzieś tak nas zainspirowała do nagrania, to taka myśl, że jeśli się ma sztywne deadline’y, sztywne terminy, jakąś datę końcową projektu czy datę wdrożenia konkretnej wersji produktu, to nie masz Agile’a, nie masz podejścia zwinnego. Już z samego faktu, że są sztywne deadline’y, które trzeba dotrzymać i to naprawdę trzeba dotrzymać, no to podejście zwinne już nie jest możliwe. I nie chcemy tutaj w tym odcinku mówić, że to jest jakiś mit albo że ktoś nam takie coś zaproponował. To jest bardzo osobiste, ale sam też miałem kiedyś z tym problem. O wiele prościej mnie samemu myślało się o podejściu zwinnym w takim świecie, w którym nie mam blokady na terminie, tylko po prostu realizuję jak najlepszą wartość i jak skończymy, to będzie. Czyli takie trochę: „Nie mogę ci podać terminu, bo jesteśmy przecież zwinni, mamy estymację, mamy możliwe zmiany w backlogu i po prostu jak skończymy, to będzie”. Wielu to denerwuje – zwłaszcza zarządzających organizacją lub osoby, które jednak tym światem takim zarządzanym przez terminy funkcjonują w biznesie, no i coś, co chcemy w tym odcinku mocno podkreślić to to, że takie myślenie, które sam też podzielałem, jest błędne. Tak naprawdę podejście zwinne umożliwia pracę z terminami czy nawet – chcemy zaryzykować taką tezę – że całkiem dobrze robią terminy, żeby w fajny sposób pracować zwinnie. Jacek: Jak myślę sobie o pracy na konkretny termin, to przypomina mi się klasyczna książka Toma DeMarco, „Zdążyć przed terminem” – taki, powiedziałbym, project managerski klasyk, który zresztą sam czytałem bardzo, bardzo dawno temu. Natomiast dlaczego wspominam o Tomie DeMarco? Ponieważ natrafiłem na – nie pamiętam czy to był wywiad czy jakiś artykuł i tutaj niestety nie będę w stanie Wam precyzyjnie wskazać źródła, natomiast odtworzę to z pamięci. Natrafiłem na artykuł, gdzie Tom DeMarco opowiedział taką historię, że pomimo tego swojego bagażu i doświadczeń – w kontekście pracy takiej na konkretny termin – no to on powiedział coś takiego, że gdyby dzisiaj miał rozwijać produkt, to oczekiwałby od zespołu, że będą mieć produkt gotowy na koniec każdej iteracji i nie będzie się dzielił z zespołem informacją, do kiedy to ma być zrobione. Po prostu zespół ma pracować tak, jakby każdy Sprint mógł potencjalnie być ostatnim Sprintem, czyli ta gotować produktowa powinna być zawsze. Nie ma opcji, że mamy coś rozgrzebane, coś w połowie, coś nie jest zintegrowane. Zawsze na koniec Sprintu czy iteracji mamy potencjalnie gotowy produkt. Kuba: Jeśli wygląda to na manipulację albo wygląda to na zbyt ostre podejście, to ja sam mam takie doświadczenia, że jeśli myślę o najsłabszym podejściu zwinnym, jakie spotkałem w jakichś organizacjach czy zespołach, to m.in. składową przyczyn, dla których ten Agile był słaby, był właśnie kompletny brak presji – albo faktyczny brak presji, albo brak zrozumienia, że ta presja jednak jest i koniec końców wreszcie się ujawni, tylko będzie już za późno. Żeby to zamienić na konkrety, naprawdę znam – czy przypominam sobie – chociażby zespół, który miał rozwijać zupełnie nowy produkt i miesiącami szykowali się do kolejnej wersji, zdążyli zmienić logo, zdążyli zmienić design strony, ale ta wersja nigdy nie ujrzała światła dziennego i koniec końców ten produkt nigdy nie ujrzał rynku, bo po prostu cierpliwość zarządzających się wyczerpała, no ale ten zespół absolutnie nie czuł presji, nie czuł, że tam trzeba się z czymś spieszyć, że trzeba zrealizować zadanie jak najwcześniej jest to możliwe. nawet jeśli nikt im nie sformułował nigdy deadline’u „Zróbcie to za trzy miesiące, bo pracujemy zwinnie”, to mimo wszystko uważam, że może by im bardzo pomogło, gdyby jednak postarali się zrobić coś całkiem dobrego jak najszybciej, a nie kisili się z kolejnymi wersjami przez długi, długi czas. Jacek: No i jak komuś to się wydaje takie ekstremalne, że jak można pracować zwinnie w tak dużym ograniczeniu, to znów przypomina mi się dyskusja na Twitterze, gdzie m.in. wypowiadał się Alistair Cockburn, czyli jeden z współtwórców Manifestu Agile, no i ogólnie osoba będąca cały czas aktywna w społeczności i dzieląca się naprawdę wartościowymi przemyśleniami, no to tam była dyskusja, gdzie

Certyfikaty w Scrumie – czy warto je zdobywać? Jakie korzyści przynoszą i komu się przydają? Co wybrać – Scrum Alliance czy Scrum.org? Jak znaleźć dobrego trenera i czy kiedyś my sami wcielimy się w taką rolę? Przesłuchaj 22. odcinek podcastu i dowiedz się, jakie jest nasze spojrzenie na temat certyfikacji w Scrumie. Zobacz wersję wideo Dodatkowe materiały Scrum Alliance Scrum.org SCRUMstudy Kto to jest Scrum Master i czym się zajmuje? Jak się rozwijać w roli Scrum Mastera? Scrum Master w nowym zespole 📄 Transkrypcja podcastu „Certyfikaty w Scrumie” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Jacek: Pod jednym z naszych ostatnich podcastów na stronie znaleźliśmy pytanie od Adama, który zapytał, co myślimy o certyfikacji. Co myślimy generalnie o certyfikacjach w Scrumie. I cały ten dzisiejszy odcinek poświęcimy właśnie na to zagadnienie. Kuba: W ramach nagrania opowiemy o tym, co sądzimy o certyfikacji, czyli wprost odpowiemy na pytanie Adama, ale skomentujemy też przemysł certyfikacyjny, jaki widzimy, że wokół tego tematu się buduje. Odpowiemy też bardzo osobiście, jak my się sami zapatrujemy na nasze trenerskie certyfikacje i ewentualne ich sobie zrobienie i skończymy poradami dla Ciebie na temat certyfikacji, jeśli chcesz zdawać certyfikat jakiś pierwszy lub kolejny, to trochę podpowiemy, jak się można do tego zabrać i jak wybrać też trenera. To zacznijmy od tej właśnie ważniejszej kwestii, czyli wprost odpowiedzi na pytanie Adama. Co, Jacek, odpowiadasz, gdy ktoś cię pyta na temat tego, jak się certyfikować i czy się w ogóle certyfikować? Jacek: No, myślę, że pierwsza taka myśl, która przychodzi mi do głowy jest taka, że to nie jest temat taki czarno-biały i powiedziałbym, że „to zależy”. I co mam na myśli, mówiąc „to zależy”? Na pewno takim aspektem bardzo wartościowym, jeśli chodzi o proces certyfikacji, jest to, że żeby podejść do certyfikacji, no to zwykle musimy poświęcić trochę czasu na to, żeby do tej certyfikacji się przygotować. I właśnie ten proces przygotowywania się, czyli zdobywania wiedzy, czytania artykułów, słuchania podcastów, czy wykonywania podejść do darmowych egzaminów online, uważam, że to jest wartościowo, sensownie spędzony czas. I sam osobiście tutaj bardzo dobrze wspominam okres, kiedy przygotowywałem się do certyfikacji PSD, czyli Professional Scrum Developer. Pamiętam, że to był taki okres czasu mniej więcej półtora miesiąca, w trakcie którego bardzo mocno zanurzyłem się w tematykę tej certyfikacji, no i w tym okresie – oprócz przeczytania niezliczonej ilości artykułów – przeczytałem cztery książki, które zawsze chciałem przeczytać, a sama certyfikacja o tyle była dla mnie istotna, że po siedmiu latach pracy jako developer, a następnie kilku latach pracy w różnych rolach, ale już nie w roli developerskiej, chciałem odświeżyć sobie wiedzę dotyczącą tego, jak być skutecznym, zwinnym developerem, więc jakby… z tej perspektywy uczenia się i zdobywania wiedzy, uważam, że podejście do certyfikacji może być fajną szansą. Kuba: Samo zdanie certyfikatu może być też dobrym dowodem tego, że jakąś tam podstawową wiedzę się już posiadło i udowodniło, że się umie nią pochwalić, czyli jak pracuje np. z początkującymi Scrum Masterami, wchodzę w jakiś taki proces rozwojowy, to jest dla mnie momentem w tym całym procesie przygotowania się do certyfikatu, czyli ta część, o której ty, Jacek, mówisz, ale też udowodnienie sobie i być może też takie trochę niezależne udowodnienie całemu światu, że nie tylko jestem Scrum Masterem, bo mój zespół tak uważa, mój manager tak uważa albo ja sam, ale też istnieje jakaś światowa instytucja, która potwierdza, że faktycznie podstawowy poziom wiedzy jakiś mam i zdałem to, przeszedłem czy zaliczyłem jakiś egzamin, co może mieć znaczenie, co może być jakimś tam argumentem przy np. rekrutacji, przy wyborze Scrum Mastera w kolejnym zespole, jeśli zmieniamy zespoły, czyli jakiś tam dowód, zaliczenie jakiegoś podstawowego poziomu teoretycznego. No i tu pasuje twoja metafora z przygotowaniem się i zdawaniem prawa jazdy. Możesz to poszerzyć? Jacek: Jasne. Jak podchodzimy do egzaminu na prawo jazdy, no to jest tam jakaś część teoretyczna oczywiście i część praktyczna. W każdym razie, jak zdamy obie części, no to dostajemy papier, który mówi: „Dana, konkretna osoba, która zdała ten egzamin, może poruszać się jakimś tam konkretnym pojazdem, w zależności od kategorii”. I teraz – czy to czyni z nas kierowcę rajdowego? Niekoniecznie. Czy to znaczy, że jeżeli weźmiemy sobie dwie losowe osoby, to czy one jeżdżą w ten sam sposób, pomimo tego, że mają ten sam dokument? No też – nie. Czyli ten certyfikat, z mojej perspektywy, on nie jest gwarantem jakości świadczonych usług – tak mówiąc trochę metaforycznie, czy tu myślimy o Product Ownerze, czy o Scrum Masterze, czy o jakiejkolwiek innej certyfikowanej roli – ale jest takim fundame

Usprawnianie procesu, nacisk położony na wszelkie kwestie organizacyjne – to znamy wszyscy. A co ze stroną produktową? Co z robieniem właściwych rzeczy zamiast ciągłego skupiania się na „polerowaniu” procesu i na pracy we właściwy sposób? Czy da się zrównoważyć te kwestie i poświęcić więcej uwagi samemu produktowi? O tym w 21. odcinku podcastu Porządny Agile. Zobacz wersję wideo Dodatkowe materiały Product Discovery Porządny Sprint Książka „The Principles of Product Development Flow: Second Generation Lean Product Development„ Donalda Reinertsena 📄Transkrypcja podcastu „Pułapka optymalizowania procesu” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Kuba: Jakiś czas temu, w trakcie wspólnego szkolenia mieliśmy taką dłuższą dyskusję na temat tego, jak usprawniać proces, jak dobrze realizować Scruma, jak w dobry sposób pracować zwinnie i taka refleksja, która nas wspólnie z Jackiem po wszystkim naszła i którą chcemy się podzielić w ramach tego odcinka, to to, że dostrzegamy bardzo duże skupienie na tej stronie optymalnego procesu, optymalnego sposobu pracy, optymalnego sposobu funkcjonowania w sposób zwinny, jeśli chodzi o przestrzeganie pewnych reguł, a za mało skupienia czy za mało uwagi na tą stronę produktową. Mówiąc w skrócie – dużo uwagi idzie na to, czy pracujemy we właściwy sposób, a nie na to, czy robimy właściwe rzeczy. Jacek: I generalnie, jakbym tak się miał zastanowić, jakie pytania słyszę najczęściej, to zwykle są to pytania, które bardzo mocno skupiają się na samym procesie wytwarzania, natomiast mało pytań, bądź w ogóle te pytania się nie pojawiają, dotyczy tego, czy tak naprawdę sensownie wykorzystujemy np. Scruma czy podejście zwinne do budowania właściwych produktów. Tej rozmowy nie ma. Myślę, że powodów jest wiele i nie chciałbym teraz w nie wchodzić, natomiast w dzisiejszym odcinku chcielibyśmy skupić się na tym, jak sensownie wykorzystać proces, ale tak, żeby nie zgubić tego, co dostarczamy przy użyciu tego procesu, czyli właściwego produktu. Kuba: Ale w pierwszej części odcinka opowiemy trochę, co mamy na myśli, gdy mówimy, że nadmiernie skupiamy się na procesie. Zwłaszcza Scrum Master może czuć, że w zasadzie cały sens istnienia jego roli, to jest: żeby zespół nauczył się Scruma, żeby go przestrzegał, żeby w sposób zwinny cała tutaj grupa produktowa pracowała. No, problemy czy przykłady tego, co mamy na myśli, że tu jest za dużo uwagi na proces, to np. nadmierne skupienie się na velocity. Mnóstwo osób patrzy na miary procesowe, miary wynikające z procesu pracy, takie bardziej generyczne albo miary procesowe wynikające z już konkretnie praktyk wokół Scruma czy w „Scrum Guidzie” zawartych. No i np. velocity zespołu staje się jedną z rzeczy, która jest omawiana na każdym Sprint Review, analizowana na każdej Retrospektywie i gdzieś tam cała gra skupiona wokół tego, czy na wykresie się wszystko dobrze poukładało, czy te Story Pointy się dobrze ułożyły w jakiś trend, a może trend jest gorszy, a może trend jest lepszy? I, okej, fajnie jest o tym porozmawiać, natomiast niech to nie będzie sztuką dla sztuki czy i jak nam się buduje wykres. Jacek: Innym przykładem takiej miary może być miara mówiąca o przewidywalności Zespołu Deweloperskiego, czyli stosunek tej ilości Story Pointów, którą zespół zaplanował czy zaprognozował na Planowaniu w stosunku do tego, co dało się dostarczyć. Co do zasady, w pewnych firmach, dla pewnych zespołów obserwowanie tej miary może być sensowne. Natomiast zbytnie skupianie się na tym, żeby tam się zawsze sumowało do stu procent może spowodować, że położymy akcent nie na to miejsce, na które byśmy chcieli. Kuba: Podobnym problemem czy podobnym przykładem skupienia się na procesie jest to, co już wspomniałem o roli Scrum Mastera, czyli jakieś takie zafiksowanie się czy zbytnie skupianie się na tym, czy na pewno jesteśmy zgodni ze Scrumem czy super przestrzegamy „Scrum Guide’a”. No i tutaj, jakby, mogą być takie ekstremalne przypadki – ale spotykałem je w życiu – że np. Product Owner odkrywa jakąś nową, ważną okazję, która może wpływać na to, jak zespół może pracować. Może to jest jakieś nowe odkrycie interesariuszy, może jakiś użytkownik coś podpowiedział, a Scrum Master mówi: „Nie, nie ma możliwości wpływania na zespół, nie możemy z nimi rozmawiać, do zobaczenia na następnym Planowaniu Sprintu”. Czyli gdzieś tam nad wartość biznesową przedkładamy to, że musimy wypełniać w każdym możliwym przypadku – włącznie z jakimiś rzadkimi, kryzysowymi sytuacjami – musimy przestrzegać tego, jak my rozumiemy czy interpretujemy Scruma. Jacek: I to w szczególności osoby, które nie do końca są fanami zmian toczących się w firmie czy samego tutaj konkretnie frameworka, no, bardzo łatwo, myślę, mogą też to wypunktować, ale tak naprawdę dyskusja toczy się o tym, czy to jest książkowy Scrum czy może jakiegoś aspektu Scruma nie wypełniamy, a t

Jaka jest definicja Sprintu? Jak powinien wyglądać Sprint? Przedstawiamy sześć porad, jak powinno się wykonywać i organizować Sprint. Niezależnie od tego, czy jesteś Agile Coachem, Scrum Masterem czy członkiem zespołu – wśród naszych propozycji możesz znaleźć taką, która korzystnie wpłynie na to, jak funkcjonuje Sprint w Twoim zespole. Jak powinien wyglądać Sprint? Jak go zdefiniować i naprawdę dobrze wykonać? Dowiedz się jak prawidłowo zorganizować Sprint, aby wykorzystać z korzyści, jakie daje. Artykuł ten dedykujemy zarówno Agile Coach’om, jak i Scrum Masterom oraz członkom zespołów, gdyż każda z tych ról ma wpływ na przebieg Sprintu.  Spis treści Jak powinien wyglądać Sprint?Jak przeprowadzić porządny Sprint?📄Transkrypcja podcastu „Porządny Sprint” Wyjdźmy od tego, czym Sprint jest, a czym nie jest. Popularnymi mitem, z jakim się spotykamy i któremu teraz chcemy stanowczo zaprzeczyć to to, że Sprint nie jest takim mini-waterfallem. “Przewodnik po Scrumie” definiuje Sprint jako: Ograniczenie czasowe (nie dłuższe niż miesiąc), w którym powstaje produkt; w ramach tego miesiąca Zespół Scrumowy wykonuje pracę, a na koniec uzyskuje Przyrost. Dodamy jeszcze tutaj ważny aspekt tego, że Scrum określa Sprint jako swego rodzaju sposób na limitowanie ryzyka, dzieląc działania na mniejsze części i ciągle sprawdzamy efekty i ewentualne problemy. Dzięki temu szybko możemy zareagować i zarządzić procesem. Jak widzisz, w Scrumie do ryzyka podchodzimy w sposób empiryczny, czyli zamiast odpowiadania sobie, jakie są ryzyka i jaki mamy plan mitygacji, to z uwagi na to, że na koniec Sprintu mamy coś dostarczyć, te ryzyka muszą być jak najbardziej widoczne i transparentne dla wszystkich zainteresowanych inicjatywą, projektem czy produktem, który rozwijamy. W wielu projektach prowadzonych bez Sprintów często jest dużo zabawy w złudzenia, że coś nadrobimy, może coś się odblokuje, może zakupiony sprzęt, na który czekamy, wreszcie dojdzie. Sprint podchodzi do takich sytuacji bardzo brutalnie: jeśli w pierwszym Sprincie Ci się nie udało, to jasno powiedzcie sobie, że mimo intensywnej pracy przez ostatni okres, nie jesteście w stanie pokazać czegokolwiek. Ma to dużą wartość, gdyż takie Przeglądy Sprintu, podczas których zespół nie jest w stanie nic pokazać, chociaż wykonał ogrom pracy, jest często mocnym impulsem, zwłaszcza dla managementu, że są jakieś przeszkody na drodze, które mogą spowodować, że możemy nie dostarczyć produktu. Jak przeprowadzić porządny Sprint? Podzielimy się teraz z Tobą 6 konkretnymi wskazówkami jak prawidłowo podchodzić do Sprintu, czyli jak przeprowadzić porządny Sprint.  Oczywiście nie wszystkie nasze porady i sugestie sprawdzą się w Twoim przypadku, dlatego zastanów się, która z nich może wesprzeć Sprinty w Twoim zespole. 1. Miej Przyrost na koniec każdego Sprintu Z naszej perspektywy takim najprostszym wskaźnikiem mówiącym o tym, czy zespół faktycznie w sensowny sposób wykorzystuje Scruma, jako narzędzie do rozwiązywania problemów jest to, czy na koniec Sprintu mamy jakiś konkretny Przyrost Produktu.  Przykładowo, jeśli tworzymy aplikację cyfrową, to mówiąc o Przyroście Produktu, mamy na myśli jakiś kawałek tej aplikacji, dający możliwość jej zobaczenia, kliknięcia, przetestowania bardzo uproszczonej funkcjonalności. Dla nas przyrostem nie jest spisana część backendowa czy stworzone makiety. To tylko elementy składowe, a to, co nas powinno interesować to to, czy potrafimy zebrać w całość te wszystkie elementy składowe tworzone przez inne osoby i co w tak krótkim okresie Sprintu jesteśmy w stanie dostarczyć. Nawiązując do wcześniej wspomnianego backendu, warto powiedzieć sobie, po co w ogóle mieć przyrost co Sprint. A to szybko przenosi nas do tematu ryzyk, bo np. właśnie mając ten backend, który nie jest jeszcze połączony z frontendem i nietworzący produktu, może zawierać w sobie wiele ryzyk jak: ryzyko integracji, ryzyko niedociągnięć technologicznych czy ryzyko złego zrozumienia wymagań. Póki nie jesteśmy w stanie całościowo spojrzeć na produkt, to nie wykryjemy tych ryzyk. Tak naprawdę to rzeczywistość i używanie produktu pokaże co nie działa. Stąd też przyrostowość, bo zrobienie nawet najprostszej wersji produktu, pozwala zbierać informację zwrotną od realnych użytkowników. 2. Rób krótkie Sprinty W “Scrum Guidzie” możesz przeczytać o Sprintach miesięcznych, jednak my zachęcamy do robienia jak najkrótszych Sprintów, nawet tygodniowych.  Spotykamy się z wieloma argumentami, że takie krótkie Sprinty są niemożliwe w danej organizacji, jednak według nas to pokazuje tylko niedoskonałości organizacji, które trzeba wyciągnąć i naprawić. Te niedoskonałości mogą być związane z technologią lub narzędziami, a uświadomienie sobie tego pozwoli zoptymalizować pracę. Oczywiście gęsta iteracja będzie brzmieć bardzo ambitnie i trzeba będzie się nauczyć nowego sposobu pracy, jednak wraz z nabieraniem wprawy będziemy widzieć coraz więcej korzyści płynących z takiego trybu pracy. W

Estymowanie to temat, który wzbudza dużo pytań oraz wątpliwości. W tym odcinku omawiamy czym jest estymowanie, przedstawiamy trzy podstawowe podejścia oraz zastanawiamy się nad sensem korzystania z estymat. Spis treści Czym jest estymowanie i jaki jest sens korzystania z estymat?Estymowanie klasyczneEstymowanie relatywneBrak estymownia📄Transkrypcja podcastu „Estymowanie” Czym jest estymowanie i jaki jest sens korzystania z estymat? Estymowanie jest procesem wyceny lub jej ekstrapolacji, które mówi nam, jak wiele zasobów (pieniędzy, wysiłku, ludzi, czasu) musimy przeznaczyć na wykonanie danego projektu czy zadania. Poznaj trzy podstawowe podejścia do estymacji w agile i przeczytaj o naszym praktycznym doświadczeniu w tej dziedzinie. Estymowanie klasyczne W najbardziej klasycznym podejściu do estymacji odpowiadamy sobie na pytanie “ile zajmie Ci/Wam to pracy?”. Przykładowo Ile godzin lub dni potrzebujecie, żeby wykonać dane zadanie? Drugie podejście bardziej skupia się na czasochłonności. Pytamy tu o to “kiedy to będzie?”. Nie interesuje nas, jak dużo pracy w tym zadaniu trzeba wykonać, chcemy znać datę, kiedy można odebrać wykonane zadanie lub kiedy dany projekt będzie skończony. Jeśli chodzi o pierwsze podejście, to ten czas może przyjmować różne jednostki, zwykle mamy tu jednak na myśli tzw. “man-day”, które po polsku możemy przetłumaczyć na roboczo-dni. Jest to skrót myślowy odnoszący się do dnia pracy jednej osoby, a dla każdego może to znaczyć przecież zupełnie co innego.  Stąd też zachęcamy Was do wykonania ćwiczenia i trakowania czasu kiedy faktycznie pracujecie. Może się okazać, że 7-8 godzin, które według Was były przeznaczone na pracę to tak naprawdę tylko 4,5, maksymalnie 6 godzin wydajnego działania. Pozostały czas to wszelkiego rodzaju przerwy na odpoczynek, odebranie telefonu czy przełączanie się między kontekstami różnych czynności. Przy pracy w biurze wchodzą tu też takie rozpraszacze jak np. szef, który przyszedł z jakąś ważną sprawą do przekazania, ktoś hałasował, ktoś wyciągnął na kawę.  Dlatego, jeśli szacujecie pracę w sposób klasyczny, to przestrzegamy Was przed zakładaniem, że jeden dzień pracy to 8 godzin, a jeden tydzień pracy to pięć dni roboczych. Tak się dzieje w naprawdę idealnych warunkach pracy, które rzadko mają miejsce. Bierzcie to pod uwagę podczas określania, ile czasu Wam coś zabierze.  Inną pułapką przy podejściu klasycznym jest prawo Parkinsona, które mówi, że praca rozszerza się tak, aby wypełnić czas dostępny na jej ukończenie. Innymi słowy, jeśli powiecie, że coś zajmie Wam tydzień to tyle faktycznie zajmie, a może nawet więcej. Warto więc zastanowić się, czy nie rozważyć nieco mniejszych estymat, które w pewnym sensie dopingują nas i motywują do tego, żeby skupić się na tym, co jest najważniejsze i dostarczyć to w pierwszej kolejności. Estymowanie w sposób klasyczny jest bardzo intuicyjne, co jest jego główną zaletą. Bardzo szybko uczymy się, ile konkretne typy zadań nam zajmują i ile jesteśmy w stanie wykonać w jeden dzień.  Natomiast największy kłopot z klasycznym estymowaniem jest z tym że estymaty często zakładają tylko ten obszar pracy, który wiemy, że jest do wykonania. Nie biorą one pod uwagę tego, o czym nie wiedzieliśmy na etapie planowania, a co pojawi się niespodziewanie w czasie pracy.  Drugą wadą tego podejścia jest taki, że w niektórych środowiskach pracy deklaracje ile coś nam zajmie czasu, są od razu zamieniane na obietnice wykonania za X czasu. W ramach zabezpieczenia się wycena ilości czasu jest zawyżana, aby mieć zapas na nieprzewidziane sytuacje i żeby wywiązać się z obietnicy.  Estymowanie relatywne Z tego powodu w podejściu zwinnym bardzo popularne jest szacowanie relatywne (względne), w którym nie szacujemy w żadnych jednostkach stałych typu dni, czy godziny, ale poprzez porównywanie zadań, elementów Backlogu czy projektów między sobą. Nie musimy tu być bardzo precyzyjni, a czas potrzebny na oszacowanie pracy do wykonania zdecydowanie się skraca.  W estymowaniu relatywnym stosujemy pewne rzędy wielkości, a zadania możemy pogrupować na małe, średnie i duże. Możemy też te grupy zamienić na pewne umowne jednostki jak np. Story Point’y. Z kolei mając dane historyczne, łatwiej będzie nam ocenić, ile w danym tygodniu jesteśmy w stanie wykonać zadań małych, średnich czy dużych.  Dodatkową bardzo korzystną praktyką związaną z estymowaniem względnym jest to, że zazwyczaj takie estymowanie robi się całym zespołem. Jest to o tyle istotne, że różne osoby mogą mieć różne wyobrażenie odnośnie do konkretnego zadania. Jeśli zespół uwspólni wiedzę na temat tego, co jest do zrobienia i tego, co jest już zrobione, jakość estymaty wzrasta, a i cały zespół ma lepsze zrozumienie przedmiotu pracy. Przestrzegamy Cię jednak przed pokusą porównywania estymat dwóch różnych zespołów. Nawet jeśli używacie takiej samej skali estymacyjnej, np. ciągu Fibonacciego, to wciąż możecie mieć całkowicie inaczej wykalibrowane jedno

Scrum jest prosty, ale bywa mylnie rozumiany. Na bazie informacji od słuchaczy wyselekcjonowaliśmy 5 najpopularniejszych mitów, nad którymi pochylamy się w tym odcinku. Zobacz wersję wideo Dodatkowe materiały Mity zwinności Cel Sprintu Dlaczego Scrum Master nie powinien być pośrednikiem? Kto to jest Scrum Master i czym się zajmuje? 📄Transkrypcja podcastu „Mity Scruma” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Kuba: W dzisiejszym odcinku chcielibyśmy kontynuować mini-cykl, który zapoczątkowaliśmy w odcinku siedemnastym, czyli „mity”. Tym razem – spośród listy rzeczy zgłoszonych przez naszych słuchaczy na naszą prośbę – wybraliśmy mity związane ściśle z frameworkiem scrumowym. Wybraliśmy pięć mitów scrumowych, które po kolei przytoczymy, wspomnimy, kto je zgłosił i trochę o nich opowiemy. Jacek: Pierwszy mit, który chcielibyśmy dzisiaj rozwiać, brzmi: „Myślenie o Sprincie jako o fazie waterfalla, tylko z inną etykietką”. Jest to mit zgłoszony przez Jakuba. Jak rozumiemy ten mit? Wyobraźmy sobie, że rozwijamy jakiś produkt, realizujemy jakiś projekt, realizujemy jakąś inicjatywę i postępujemy takim bardzo klasycznym sposobem, czyli najpierw jest jakaś analiza, jakieś projektowanie – to są takie fazy, które toczą się gdzieś tam, nie wiadomo gdzie, ale na pewno poza Zespołem Deweloperskim i w momencie kiedy specyfikacja naszego rozwiązania jest gotowa, jest podpisana, jest zatwierdzona przez wszystkie ważne osoby w procesie… Kuba: I może nawet jeszcze architektura jest już rozpisana. I całe rozwiązanie jest zaplanowane. Jacek: Czyli wszystko jest bardzo dobrze przygotowane, no to wtedy pojawia się zespół, wtedy się pojawia Scrum, i tak naprawdę ten Scrum jest pewną fazą wytwarzania, natomiast, no, absolutnie umocowaną w procesie waterfallowym. No i jeśliby się zastanowić nad tym mitem, no to tak, po pierwsze: absolutnie nie jest tak, że Scrum jest tylko etapem pracy w waterfallu. Idąc dalej, takie podejście do wykorzystania Scruma, no to jest jak kupić samochód wyścigowy, no i próbować nim jeździć po lesie – tak naprawdę nie będzie z tego żadnego sensownego efektu, a tylko będziemy mogli sobie zrobić krzywdę. Kuba: Rozsupłując tą twoją metaforę, chodzi o to, że mamy podejście, które umożliwia elastyczność, kreatywność, wymyślanie jak najszybszych i wartościowych rozwiązań na wskazany problem – i odbieramy sobie tą możliwość, ponieważ zespołowi jest zlecany szczegółowy zakres, nie ma więcej pytań, ma być po prostu to precyzyjnie wykonane. W ogóle nie dajemy okazji, żeby wykorzystać potencjał zespołu, tylko sprowadzamy Scrum jako metodę kontroli zespołu. Jacek: Tak. Kuba: Smutna rzeczywistość – bywa tak w firmach, ale to jest zdecydowanie mit i niewłaściwe wykorzystanie Scruma. Jacek: Bardzo popularnym określeniem, które możesz spotkać w kontekście tego, o czym teraz opowiadamy, jest pojęcie Water-Scrum-Fall, gdzie tak naprawdę Scrum jest tylko pewnym elementem – tak jak, Kuba, powiedziałeś – takim pewnym uproszczeniem, często narzędziem kontroli, a przede wszystkim narzędziem, które tak zastosowane sprowadza zespół do takiej roli mocno podwykonawczej, gdzie po prostu mają za zadanie w pewnych iteracjach dostarczać wymagania, które zostały zdefiniowane. I, no, taka historia, którą ostatnio doświadczyłem – pracując z jedną z firm – było… sytuacja, w której Zespół Deweloperski otrzymał specyfikację. Ta specyfikacja była wytwarzana wcześniej przez… no, dobrych kilka miesięcy. Zespół dostał tą specyfikację i kiedy zapytałem jednego z Deweloperów, jak im idzie praca, na ile ten dokument jest dla nich przydatny, no to ten Deweloper się tylko uśmiechnął i powiedział: „3/4 tej analizy poszła do kosza”, ponieważ dopiero jak rozpoczęli faktyczną pracę, no to zaczęli natrafiać na problemy, których nikt wcześniej z wyprzedzeniem nie przewidział. No i to jest przykład na to, że de facto pewnego rodzaju marnotrawstwem jest taka „nadprodukcja” i stosowanie tylko Scruma, jako narzędzia, żeby je wykonać czy dostarczyć. Kuba: I to, co wspomniałeś, to jest klasyk tego zjawiska – próby rozwiązywania złożonego problemu. Tego nie zaplanujemy, mocno o tym już mówiliśmy w odcinku siedemnastym, który – jak zwykle – zalinkujemy w opisie odcinka. Jacek: Dobrze. Kuba: Drugim mitem scrumowym, który wybraliśmy, jest mit zgłoszony przez Krystiana: „W Scrumie nie ma roadmapy„. I faktycznie rozumiem, z czego taki mit może wynikać, bo jeślibyśmy wrócili do „Przewodnika po Scrumie”, to faktycznie tam raczej słowo „roadmapa” nie jest zbytnio widoczne, a też takie zapalczywe, wczesne podejście do Scruma – zwłaszcza jako alternatywy do waterfalla – no to będzie takie podejście: „No, mamy Backlog” czyli: mamy wszystko, nic więcej nie musimy planować, nic nie musimy nigdzie nikomu raportować,

Jakie są mity zwinności? Nagraliśmy odcinek o nieporozumieniach, które przez lata nagromadziły się wokół agile’a. W odcinku poddaliśmy pod dyskusję najpopularniejsze z nich, które zgłosili nam nasi słuchacze. Zobacz wersję wideo Dodatkowe materiały Rola analityka w agile Product Discovery artykuł Czym jest agile? naszego autorstwa artykuł „Czym jest Scrum” z serii Agile Starter na Agile247 Manifest Agile Model Cynefin 📄Transkrypcja podcastu „Mity zwinności” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Jacek: Jakiś czas temu zapytaliśmy was, jaki znacie popularne mity zwinności, dotyczące Agile’a i Scruma. W dzisiejszym odcinku przyjrzymy się pięciu najpopularniejszym mitom dotyczącym podejścia zwinnego. Będzie to odcinek, który nagrywamy w nieco innej formule. Będzie to odcinek krótszy niż zazwyczaj – będziemy celować z Kubą w 30 minut i zmienia się też równocześnie nasza częstotliwość wydawania podcastu. Dotychczas była to co trzecia środa, natomiast startując od dzisiejszego, siedemnastego już odcinka podcastu, chcemy release’ować ten podcast co dwa tygodnie. Kuba: W przybliżeniu, bo zobaczymy, jak wypadnie okres świąteczny, ale spróbujemy trochę częściej, trochę krótsze nagrania. Jacek: Dobrze, Kuba, jakie są te mity związane z Agile’em i z podejściem zwinnym? Kuba: Wybraliśmy pięć spośród zgłoszonych przez poszczególne osoby. Nie opowiemy wszystkich, ale chcemy zacząć od takiego najbardziej związanego z podejściem zwinnym, czyli mit, że waterfall jest zawsze zły – konkretnie takie stwierdzenie nam podsunął Kamil. No i… Porządny Agile, podcast o Agile’u – czy waterfall zawsze jest zły? Jacek: No tak, chyba powinniśmy powiedzieć, że tak właśnie jest. Kuba: W końcu jesteśmy zwinni, więc naszym naturalnym wrogiem jest waterfall. Jacek: Tak, natomiast, moje takie główne przemyślenie, jak widzę tego rodzaju sformułowania, że coś jest zawsze jakieś, no to pierwsza myśl, która mi przychodzi do głowy, jest taka, że – co do zasady – nie wierzę w to, że istnieją perfekcyjne narzędzia, które rozwiązują wszystkie problemy, tak więc taki absolutnie pierwszy odruch, nie wchodząc w jakieś konkretne modele czy frameworki, mój pierwszy odruch jest taki – że nie. To nie jest tak, że waterfall jest zawsze zły. Kuba: Na zasadzie – bo nic nie jest zawsze złe lub dobre, tak? Jacek: Dokładnie tak. Kuba: Mhm. Jacek: Natomiast wchodząc głębiej, to myślę, że takim dobrym modelem, czy dobrym narzędziem, które pomaga znaleźć odpowiedź na to pytanie jest Cynefin. I osobiście bardzo często rozpoczynam szkolenia, które prowadzę – dotyczące podejścia zwinnego – właśnie od tego modelu, który definiuje pięć głównych domen, pięć głównych obszarów, które różnią się od siebie złożonością, czyli mamy obszar prosty, skomplikowany, złożony, jest też obszar chaotyczny i pośrodku Disorder, czyli obszar, w którym do końca nie wiemy, w jakim obszarze jesteśmy. I jeśli mówimy o tym obszarze prostym, gdzie istnieją najlepsze praktyki, gdzie istnieje superwidoczna zależność przyczynowo-skutkowa, no to to… problemy z tej domeny, moim zdaniem, mogą być rozwiązywane podejściem waterfallowym, czyli takim podejściem, gdzie jesteśmy w stanie sobie przeanalizować problem, zaplanować i po prostu go wykonać. No i szansa, że wydarzy się coś nieprzewidywalnego jest bardzo mała. Kuba: Takie typowe waterfallowe nadaje się też do domeny skomplikowanej, gdzie też trzeba zaplanować sobie pracę, zrozumieć zjawisko, ten świat skomplikowany, to jest świat, w którym świetnie sprawdzają się eksperci, którzy już mają wiedzę, oni już wiedzą, jak to trzeba rozwiązać, tylko po prostu sprawie się trzeba głęboko przyjrzeć, zastanowić, przemyśleć alternatywy, dobrać różne jakieś rozwiązania czy metody, czy jakieś pomysły-  spośród już istniejących dobrych praktyk – wszystko złożyć w jakąś ideę, plan – i po prostu to wykonać. I uzyskać spodziewany rezultat, bo tu nadal związek przyczynowo-skutkowy jest między „A, B i C łącznie dają nam D”, a ponieważ chcemy uzyskać „D”, no to trzeba wykonać te trzy wcześniejsze kroki, czyli takie też podejście planistyczne. Ta granica wynikająca właśnie z Cynefina tu ewidentnie leży na tym, czy jesteśmy w stanie wszystko wiedzieć, czy znamy już te rzeczy, które są nam znane oraz znamy te rzeczy, nad którymi się jeszcze musimy zastanowić, ale jest ich skończona ilość. Natomiast domena złożona – ten świat, który też się nadaje świetnie do Agile’a – a akurat podejście takie waterfallowe, planistyczne tam nie gra, no to to jest świat, w którym nie wiemy, czego nie wiemy. Czyli są jakieś zmienne czy jakieś takie… wymiary, w których po prostu nawet nie zdajemy sobie sprawy, bo nigdy tego nie robiliśmy, bo tak działa świat, bo taka jest historia, nie wiem, na rynku tak funkcjonuje nasz produkt, że są po prostu takie zmienne, któr

Samoorganizacja jest dobrym pomysłem, popularnym w podejściu zwinnym, ale co zrobić jeśli w zespole mamy kogoś bez zaangażowania? Temat wraca nam w pytaniach na spotkaniach społeczności i w trakcie naszej pracy w roli Agile Coacha, więc w odcinku szesnastym pochylamy się nad tą trudną sytuacją. Zobacz wersję wideo Materiały dodatkowe Praktyka „Moving Motivators” z Management 3.0 – https://management30.com/practice/moving-motivators/ FUKO – technika formułowania informacji zwrotnej – http://www.agile247.pl/fuko-i-sbi-2-proste-narzedzia-do-dawania-informacji-zwrotnej/ 📄 Transkrypcja podcastu „Niezaangażowany członek zespołu” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Kuba: W dzisiejszym odcinku poruszymy temat problemu z pojedynczym członkiem zespołu. Chcemy go zdefiniować jako problemu z angażowaniem się czy z zaangażowaniem wybranego członka zespołu. W ramach odcinka zdefiniujemy, co dokładnie mamy na myśli i przejdziemy przez to, jak zdiagnozować, czy dokładnie mamy ten przypadek, czy mamy do czynienia z nim w naszym zespole. Porozmawiamy o tym, jakie widzimy możliwe narzędzia, praktyki czy sposoby rozwiązania problemu z zaangażowaniem członków zespołu i skończymy z takimi najmocniejszym środkami, które są takimi środkami ostatecznymi, jeśli jako zespół sobie z tym nie radzimy. Jacek: Tłem tego odcinka są takie dwa główne przypadki. Pierwszy przypadek to jest kiedy pracujemy jako zewnętrzni konsultanci z firmami i sami na własne oczy widzimy takie osoby w zespołach. Drugi przypadek jest taki – dostajemy pytania na konferencjach czy pracując z ludźmi 1 na 1, jak my radzimy sobie w takich sytuacjach, kiedy widzimy, że jakiś członek zespołu nie angażuje się. No i dostajemy pytania, co byśmy rekomendowali w takiej sytuacji. Kuba: I te pytania pojawiają się na tyle regularnie, że założyliśmy, że to może być interesujący temat, żeby poświęcić temu cały odcinek. Jakie jest tło, dlaczego jest to w ogóle ważne, to trzeba podkreślić to, że – zwłaszcza jak jesteśmy na szkoleniu, to bardzo fajnie i przekonywająco opowiadamy o tym, że zespół zwinny angażuje się, samoorganizuje się, współdzieli pewne wartości – i to, co do zasady jest prawda. Co do zasady, ludzie są dobrzy, chcą, chcą wykonywać dobrą robotę, natomiast poszczególne osoby mogą mieć doświadczenie – osoby, które uczestniczą w naszym szkoleniu – mogą mieć jakieś doświadczenie z przeszłości czy ze swoich bieżących zespołów, że mają jakiś przypadek osoby, która nie ma pracuje tak samo mocno jak inni. I to może mieć różny wymiar – bo to może być np. bardzo intensywne spóźnianie się, wczesne wychodzenie, jakieś takie, nazwę to, „ściemnianie”, czyli próba udawania, że się pracuje, ale się jednak nie pracuje. Ale to też może być wykonywanie pracy, ale jednak z o wiele mniejszą odpowiedzialnością – to jest takie nierealizowanie zadań, do których się zobowiązuje, niespełnianie obietnic względem zespołu, niedostarczenie rozwiązań w takim standardzie jakościowym, w jakim wszyscy to oczekują. Czyli szereg takich sytuacji, które powodują, że pozostali członkowie zespołu nie mogą na takiej osobie polegać. Mają prawo mieć pretensje, no i też efekt pracy całego zespołu jest zawalony, no bo pojedynczy członek zespołu nie realizuje – i to nie realizuje w sposób taki, ja bym powiedział, trwały – swoich prac, swoich zadań. Nie wywiązuje się ze swoich zobowiązań, pomimo tego, że wcześniej deklarował różne tego typu obietnice czy obiecywał, że się wywiąże. Jacek: Jak o tym opowiadasz, to mam przed oczami taką historię, gdzie tego rodzaju zachowanie jednego z członków zespołu powodowało demotywację u pozostałej części – na zasadzie: skoro my się angażujemy, skoro my się staramy, skoro my trochę wręcz wychodzimy przed szereg, no to nie akceptujemy tego, że w tym całym zaangażowaniu, nie to, że pracuje po prostu normalnie tylko wyraźnie widzimy, że tą osobę stać na więcej, mogłaby prezentować zupełnie inne podejście, natomiast, no, rzeczywistość jest taka, że kompletnie odstaje do zespołu no i zaczyna to powodować narastający problem. Kuba: I takie bardzo ważne zastrzeżenie na początku tego odcinka – zwłaszcza dla osób, które z nami współpracują bezpośrednio, gdy pracujemy jako konsultanci czy wcześniej pracowaliśmy jako Agile Coache czy Scrum Masterzy, ten odcinek nie jest o konkretnym, pojedynczym przypadku czy konkretnej pojedynczej osobie. Gdy się przygotowywaliśmy do nagrania, wymieniliśmy sobie szereg… pewnie doszliśmy do kilkunastu takich praktycznych przypadków. My chcemy go tutaj potraktować bardzo generalnie, więc nie mamy na myśli żadnej konkretnej osoby czy żadnego konkretnego zespołu z konkretnych firm. Przeżywaliśmy to wielokrotnie, to nie jest przypadek pojedynczy, jednostkowy, to się może zdarzyć. Chcemy zgeneralizowane rady dać, jakby postępować w takich przypadkach. Jacek: No dobrze, Kuba, to po czym,

Kim jest Agile Coach i jaka jest jego rola w organizacji? Czy to po prostu doświadczony Scrum Master? A może ścieżka kariery osoby chcącej zostać Agile Coachem, przebiega zupełnie inaczej? Definiujemy rolę Agile Coacha i wskazujemy różnicę między nim, a Scrum Masterem. W tym artykule znajdziesz następujące treści: Spis treści Kim jest Agile Coach?Co robi na co dzień Agile Coach?Jaka jest różnica między Agile Coachem a Scrum Masterem?Mity dotyczące roli Agile Coach’aAgile Coach wewnętrzny i zewnętrznyJak zostać Agile Coachem?Podsumowanie📄Transkrypcja podcastu „Kto to jest Agile Coach” Kim jest Agile Coach? Najprościej ujmując Agile Coach to osoba, która ma duże doświadczenie i wiedzę w pracy zwinnej. Swoje kompetencje wykorzystuje, pracując z organizacją, używając do tego różnych technik, podejść i skupiając się na różnych obszarach swojej pracy. Agile Coacha od Scrum Mastera różni przede wszystkim to, że ten drugi jest związany konkretnie z frameworkiem Scrum, natomiast Agile Coach może pracować w środowiskach zwinnych wykorzystujących różne frameworki. Dzięki temu Agile Coach patrzy trochę szerzej i wykorzystuje szerokie spektrum technik, łącząc je ze sobą i dopasowując do konkretnego zespołu oraz organizacji. To szersze spojrzenie Agile Coacha może dotyczyć całościowej zmiany toczącej się w firmie, a nie tylko z perspektywy zespołu, obszaru bądź jakiegoś konkretnego produktu. Co robi na co dzień Agile Coach? Agile Coach zwykle nie wspiera pojedynczego zespołu, jednak przejściowo może się zdarzyć, że opiekuje się konkretnym zespołem w celu wsparcia go, na przykład w kryzysowej sytuacji. Jednak po wykonaniu swojego zadania i osiągnięciu celu, ponownie wraca do pracy z perspektywy całej organizacji lub przechodzi do innego zespołu. Ważnym obszarem działania Agile Coacha jest praca ze zmianą, czy to na poziomie całej organizacji, czy mniejszego, wybranego obszaru. Wspiera on osoby przeprowadzające tę zmianę i posiada zestaw narzędzi do wykorzystania na każdym etapie transformacji.  Do zadań Agile Coacha należy także kreowanie wewnętrznej społeczności, np. w celu wymiany wiedzy lub po prostu integracji różnych środowisk. Wspiera to nie tylko budowanie więzi i nawiązywania znajomości, ale także wspólne rozwiązywanie większych problemów organizacyjnych.   Ważnym aspektem pracy Agile Coacha jest aspekt uczenia innych. Może przybierać to formę, w której Agile Coach wchodzi w rolę nauczyciela, który uzupełnia braki, pokazuje nowe techniki i pracy i sposoby podchodzenia do problemów. Może też pracować jako mentor, który pracuje 1 na 1 z wybraną osobą i dzieli się swoim praktycznym doświadczeniem. W roli mentora Agile Coach często pracuje z osobami z zarządu, wspierając podejście zwinne, a także budowanie nawyków już od najwyższego szczebla w organizacji. Odbywa się to między innymi poprzez uczestniczenie w warsztatach przygotowujących zmiany organizacyjne (np. procesów czy struktur) oparte na faktach i na zadowoleniu użytkownika czy klienta. Może się wydawać, że jest to rola Scrum Mastera, jednak w przypadku pracy wyższego kierownictwa trudno będzie sprawić, aby wdrożyć tam działania oparte na Scrumie, jednak wypracowanie myślenia zwinnego już jak najbardziej jest możliwe. Jest to istotny element pracy Agile Coacha, gdyż poświęcenie dużo uwagi decydentom organizacji, może bardzo mocno wpłynąć na toczącą się zmianę, na usprawnienie procesów wewnętrznych i biznesowych, a także na polepszenie satysfakcji ludzi. Jaka jest różnica między Agile Coachem a Scrum Masterem? Ponieważ nieuchronnie porównujemy Agile Coacha i Scrum Mastera, to wymienimy główne różnice między tymi dwiema profesjami. Pierwszą różnicą jest doświadczenie. Scrum Master wchodząc w swoją rolę, nie musi posiadać aż tak rozbudowanego doświadczenia pracy ze Scrumem, natomiast Agile Coach powinien je mieć. Buduje je dzięki współpracy z wieloma zespołami, kontekstami i organizacjami.  Ponadto, co już wspomnieliśmy wcześniej, Scrum Master zwykle skupia się głównie na Scrumie, natomiast od Agile Coacha oczekiwalibyśmy raczej, że zna on też inne frameworki, metody i techniki pracy. Ma on bardziej uniwersalne podejście, co może objawiać się tym, że nie próbuje wszędzie wmontowywać Scruma, bo wie, że takie działanie nie zawsze ma sens. Kolejną różnicą jest to, że Scrum Master operuje wokół pracy zespołowej, Agile Coach natomiast może pracować z kilkoma zespołami lub też zespołami, w których Scrum nie jest sensownym rozwiązaniem. Mity dotyczące roli Agile Coach’a Na temat roli Agile Coach’a krąży wiele mitów, które warto rozwiać. 1. Agile Coach to po prostu Senior Scrum Master Tak jak wspomnieliśmy wyżej Agile Coach, ma szerszą perspektywę, zna wiele technik pracy zwinnej i z nich korzysta, łączy je, modyfikuje. Nie ogranicza się jedynie do Scruma. Ponadto pracuje z wieloma zespołami, a także z managementem organizacji. Mylenie Agile Coach’a z bardziej doświadczonym Scrum Masterem, może wynikać z braku oficjalnej definicji tej pozy

Dużo mówi się o korzyściach ze zwinnego podejścia, ale dla równowagi warto podkreślić, że wymaga ono również poniesienia pewnych kosztów. Bez konkretnych inwestycji w transformację zwinną oraz bez ponoszenia stałych kosztów, jakich można się spodziewać po rozpoczęciu korzystania ze zwinnych metod nie możemy się spodziewać pozytywnych rezultatów. W tym odcinku bez owijania w bawełnę wymieniamy wszystkie koszty, jakich naszym zdaniem można się spodziewać, w przypadku niektórych podajemy też rzędy wielkości kwot. Zobacz wersję wideo Warto wziąć sobie do serca myśl z końca odcinka – jeśli niedoinwestujemy poszczególne niezbędne obszary, możemy zapłacić niespodziewanie największy z kosztów – „koszt zawiedzionych nadziei”. Jeśli są jeszcze jakieś koszty o których zapomnieliśmy, a które Twoim zdaniem są ważne przy transformacji w stronę agile lub podczas codziennego wykorzystywania zwinnego podejścia, koniecznie daj znać w komentarzu pod wpisem, dzięki temu ten materiał będzie jeszcze pełniejszy. 📄Transkrypcja podcastu „Koszty podejścia zwinnego” Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”. Kuba: W dzisiejszym odcinku poruszymy temat kosztów, jakie wiążą się z podejściem zwinnym. Porozmawiamy o tym, jakie są koszty wprowadzania podejścia zwinnego do organizacji i koszty, które moglibyśmy wiązać z transformacją zwinną, ale też koszty funkcjonowania zespołów zwinnych, już gdy pracują w dalszym okresie czasu i skończymy odcinek pewnymi kosztami, które uznajemy za nieoczywiste – takie, o których rzadko się mówi. Jacek: Temat jest o tyle interesujący, że dookoła nas słyszy się bardzo dużo na temat tego, jak Agile jest skuteczny, jak Agile jest efektywny, dlaczego warto przejść na Agile, pracować zwinnie itd., natomiast w tym całym takim hypie i otoczce, że wszystko będzie pięknie i kolorowo, często zapomina się o tym, że to nie jest tak, że to podejście sobie bierzemy, implementujemy, próbujemy je wykorzystać w naszej firmie i to po prostu jest bezkosztowe. Tych kosztów jest, jak się za chwilę przekonasz, całkiem sporo – i intencją tego odcinka jest pokazanie tej takiej… kosztowej, chciałem powiedzieć „ciemniejszej”, ale… kosztowej strony podejścia winnego. Kuba: Nieodłączną częścią korzyści z podejścia zwinnego są również inwestycje, jakie w to podejście trzeba włożyć, nie zapominajmy o tym, nie udawajmy, że te koszty nie są potrzebne. Niektóre z tych rzeczy – gdy rozmawialiśmy i budowaliśmy listę, której na razie nie będziemy ujawniać, ale będzie się w toku odcinka zapełniać – niektóre z tych rzeczy, mamy poczucie, że mogą być dla niektórych z was oczywiste, a jednocześnie za często spotykamy w naszej praktyce pracy z organizacjami, że o pewnych rzeczach się zapomina, pewnych rzeczy się nie docenia, pewne rzeczy myśli się, że się poniesie je raz i później już nigdy nie trzeba do tego wracać, dlatego konsekwentnie zrobiliśmy taki zrzut z naszej własnej listy wszystkiego, co nam się wiąże z kosztami, nawet jeśli niektóre z tych rzeczy są dosyć proste i oczywiste. Zdajemy sobie też sprawę, że być może są jakieś koszty, o których nie pomyśleliśmy, a są specyficzne dla konkretnej organizacji – siłą rzeczy nie pokryjemy absolutnie wszystkiego i od razu sobie to powiedzmy wprost – taka refleksja, jaką teraz przeprowadzimy przez cały odcinek, jest do zrobienia w ramach każdej organizacji, w ramach rozpoczynania planowania transformacji, jak i też w toku kolejnych lat funkcjonowania Agile’a i rozmowy o tym, jakie koszty są potrzebne do poniesienia. To może zacznijmy od tych, które same się nasuwają jako te, które uznajemy za oczywiste, ale na pewno uznajemy, że są potrzebne w ramach zwinności. Jacek: Pierwszym kosztem, który warto rozważyć – w szczególności, jeżeli chcemy podejść do podejścia zwinnego w sposób profesjonalny, być przygotowanym na to, żeby sensownie z tego podejścia skorzystać, są koszty szkoleń – szkoleń w rozumieniu takim, że jesteśmy w stanie ponieść koszt tego, że konkretne osoby z firmy spędzą określoną ilość dni szkoleniowych, podczas których zdobędą wiedzę, często podstawową, która pozwoli im, po pierwsze, zrozumieć, czym jest podejście zwinne, zrozumieć, czym się różni od podejścia klasycznego oraz szkolenia te pozwolą dostarczyć jakichś takich podstawowych narzędzi i pomogą osobom, które na tych szkoleniach będą, wyjść z takim poczuciem, że mniej więcej już wiedzą, o co chodzi z podejściem zwinnym – idealnie gdyby te osoby wyszły z takim zestawem startowym, pozwalającym im rozpocząć pracę w inny sposób. Kuba: Coś, co chcemy zawrzeć, przynajmniej w niektórych punktach, o których rozmawiamy, to konkretne kwoty czy rzędy wielkości, jak według naszego rozeznania rynku kształtują się takie wielkości – i szkolenia tutaj mogą kształtować się bardzo różnorodnie cenowo – tak okrągło mówiąc, bym powiedział, że to może być do kilku tysięcy za ucze

Planowanie Sprintu rodzi wiele pytań w zespole. Przedstawiamy Sprint Planning, analizujemy to wydarzenie z różnych perspektyw a w drugiej części materiału dzielimy się praktycznymi poradami, które można wykorzystać od zaraz, podczas najbliższego planowania. W tym artykule poruszymy następujące kwestie: Spis treści Czym jest Planowanie Sprintu?Jak powinno wyglądać Planowanie Sprintu?Jak porządnie zrealizować Planowanie Sprintu?📄Transkrypcja podcastu „Porządne Planowanie Sprintu” Czym jest Planowanie Sprintu? Najprościej mówiąc Planowanie Sprintu, jest wydarzeniem Scrumowym, podczas którego Zespół Scrumowy ustala pracę na nadchodzący Sprint. Planowanie można podzielić na dwie części. Pierwsza część odpowiada nam na pytanie: co będziemy realizować?, natomiast druga część na pytanie: jak tę konkretną pracę będziemy wykonywać jako zespół?  Istotne jest tu to, że to Deweloperzy (w Scrumowym rozumieniu tego słowa) decydują, ile faktycznie pracy są w stanie wykonać, opierając się na danych historycznych. To rozróżnienie na dwa etapy ma ciekawe korzenie historyczne. Na szkoleniu Certified Scrum Master w 2009 roku uczono nas, że Planowanie Sprintu składa się z dwóch osobnych, wyraźnie odróżnialnych części – ustalenie zakresu Sprintu i ustalenie planu pracy w Sprincie. Historycznie były to dwie wyraźne, oddzielne czynności. Jedna z kolejnych aktualizacji Scruma trochę zatarła to rozróżnienie, a te obie aktywności (Plan pracy i jej zakres) dzieją się w miarę równolegle lub naprzemiennie i nie są wyraźnie odseparowane. W ramach Planowania Sprintu powstaje Cel Sprintu, jeśli temat jest dla Ciebie interesujący, zapoznaj się też z podlinkowanym materiałem. Zarówno Planowanie Sprintu, jak i Cel Sprintu, dążą do tego, aby w każdym Sprincie powstał Przyrost Produktu, będący efektem pracy całego Zespołu Scrumowego. Jak powinno wyglądać Planowanie Sprintu? Różne zespoły planują na różne sposoby i nie ma jednoznacznie najlepszego podejścia. Nie w każdym zespole każda metoda zadziała, a bywa też tak, że są konkretne konteksty funkcjonowania zespołu, od których skuteczność tych metod może zależeć.  Przedstawimy to na przykładach i trochę przez pokazanie pewnych kontrastów, jakie w różnych zespołach mogą funkcjonować. Nic też nie stoi też na przeszkodzie, żeby spróbować różnych stylów planowania i zobaczyć czy czasami nie jesteśmy zespołem, który na siłę planuje bardzo szczegółowo, mimo że nasza domena na to nie pozwala. Zawsze jakiś Plan jesteśmy w stanie przygotować, ale jego konkretny kształt niech kształtuje się na bazie kolejnych prób i rosnącego doświadczenia. Budować dokładny plan pracy czy tylko zarys działania? Pierwszym spektrum jest kontrast: przygotowanie na Planowaniu Sprintu i realizowanie bardzo dokładnego planu pracy, jako przeciwieństwo sformułowania po prostu celu i realizowania planu trochę ad hoc i wyłaniania się go trochę w trakcie Sprintu.  Z naszych doświadczeń wynika, że ​​im bardziej Zespół rozumie produkt i im lepiej zna swoje możliwości, tym bardziej jest on w stanie przygotować bardzo konkretny Plan. Czyli wiemy dokładnie, jakie zadania wykonamy, kto wykona te zadania i potrafimy mniej więcej osadzić to w czasie. Im krótszy Sprint, tym ta precyzja jest większa.  Dzięki temu powstaje plan, który możemy sobie prześledzić dzień po dniu, osoba po osobie i rysuje on nam szkic działania na najbliższe dni. Przeciwieństwem tego jest sytuacja, w której Zespół właśnie wykonuje jakieś bardzo złożone przedsięwzięcie, być może bardzo eksperymentalne, którego nikt jeszcze przed nimi nie zrobił. Tak naprawdę bardziej jest to projekt badawczy, a Zespół próbuje wpaść na rozwiązanie. Stąd na etapie rozpoczynania kolejnej iteracji prac, Zespół nie ma zielonego pojęcia, jak długo zajmie im przygotowanie tego rozwiązania czy produktu, którego jeszcze nigdy nikt nie wymyślił.  Dlatego tu Zespół będzie operować na poziomie celów: jakie ma ambicję osiągnąć? jakie ma pomysły na pierwsze działania? Z takiego podejścia nie da się najczęściej uzyskać więcej niż szkicu Planu. Dodatkowo ten szkic nie przeżywa pierwszego kontaktu z rzeczywistością, zwykle już pierwszego-drugiego dnia Sprintu widać, że plan się rozsypuje (z powodu negatywnego rozwoju sytuacji, przedłużania pracy, czy odkrycia elementów niemożliwych do realizacji). Czasami dochodzi do paradoksu, w którym plan był dłużej tworzony, niż pozostał aktualny. W takiej sytuacji bardziej istotne jest, by zespół znał cel swojego działania i ustalił schemat jak będzie przebiegać praca. Takie podejście wcale nie stoi w sprzeczności ze Scrumem, bo pamiętajmy, że Zespół ma do dyspozycji Codzienny Scrum, żeby codziennie ustalać plan działania na bardzo precyzyjnym poziomie. Planować stały zakres rozwiązania czy przewidzieć eksperymenty? Kolejny kontrast w podejściu do planowania, to planowanie znanego rozwiązania (ze znanym stałym zakresem), albo planowanie eksperymentów (gdzie rozwiązanie pojawi się dopiero w środku Sprintu).  W te

Dołączenie do nowego zespołu może być stresujące nawet dla doświadczonego Scrum Mastera. Dzielimy się naszymi podpowiedziami na temat kroków, które warto uwzględnić, gdy zmieniamy zespół i rozpoczynamy pracę w roli Scrum Mastera, nawet już z niemałym bagażem doświadczenia. Myślimy, że w tej liście inspiracji każdy znajdzie coś do rozważenia dla siebie na przyszłość. Zazwyczaj Scrum Master trafia do nowego zespołu w 2 przypadkach: całkowita zmiana firmy, zmiana zespołu wewnątrz tej samej organizacji. Są też oczywiście inne okoliczności dołączania Scrum Mastera do nowego zespołu, jak np. startowanie zupełnie nowego zespołu, gdy Scrum Master pomaga rozpocząć grupie współpracę. W tym artykule odniesiemy się jednak tylko do przypadku, gdy doświadczony Scrum Master dołącza do już zbudowanego i wcześniej pracującego ze sobą zespołu. Spis treści Dlaczego ważne jest dobre rozpoczęcie współpracy w nowym zespole?Jak dobrze przejść proces wchodzenia do nowego Zespołu Scrumowego?Przestrogi dla Scrum Mastera w nowym zespole📄Transkrypcja podcastu „Scrum Master w nowym zespole„ Dlaczego ważne jest dobre rozpoczęcie współpracy w nowym zespole? Zacznijmy od tego, dlaczego jest to naszym zdaniem istotny temat i warto go poruszyć. Przede wszystkim, z perspektywy Scrum Mastera duże znaczenie ma tzw. pierwsze wrażenie. Po drugie, z perspektywy zespołu i organizacji, to szansa na wprowadzenie trochę świeżości do funkcjonowania grupy. Stąd też warto świadomie wykorzystać ten moment, czerpiąc z niego korzyści, jakie ze sobą niesie. Jako Scrum Master, musisz odpowiednio się przygotować, aby uniknąć stworzenia złego wrażenia od samego początku. Ponadto, zwłaszcza gdy w organizacji nie ma świadomości roli Scrum Mastera, jest to idealny moment, aby wyjaśnić, czym się zajmuje Scrum Master i dlaczego warto, aby współpracował z zespołem. Warto też mieć w pamięci, że zespół ma jakąś historię i doświadczenia, które niekoniecznie mogą być pozytywne, jeśli chodzi o współpracę ze Scrum Masterem. Brak czułości na ten aspekt może sprawić, że wchodząc do zespołu, który ma złe skojarzenia z rolą Scrum Mastera, jeszcze bardziej utrudnisz sobie nawiązanie dobrej relacji. Możesz też mieć do czynienia z pewną niekompatybilnością na linii Scrum Master a Zespół Deweloperski. Taka sytuacja może zajść np. gdy dołączasz do dojrzałego już zespołu, który może mieć inne oczekiwania co do Twojego wsparcia jako Scrum Master, niż Ci się wydaje. Efektem tego może być poczucie dyskomfortu po obu stronach, zwłaszcza jeśli zespół nie powie o swoich oczekiwaniach na głos. Powodów tej niekompatybilności może być rzecz jasna więcej. Oprócz dojrzałości czy doświadczenia zespołu powodem może być również specyficzna energia i kultura zespołu – jeden zespół lubi pożartować, inny jest bardziej poważny. Jeden ma duże skupienie na kwestie techniczne i detale, z kolei dla innego ważna jest miła atmosfera i komunikacja. Scrum Master na kwestie te może zareagować, dostosowując się do zespołu lub próbując go zmienić, bo ma inne przekonania co do organizacji zespołu. Stąd też te pierwsze dni mogą zaważyć o dalszej współpracy i nastawienia zespołu do Scrum mastera albo Scrum mastera do zespołu. Ta niekompatybilność może wyjść np. podczas Retrospektywy Sprintu, kiedy to Scrum Master dobiera bardziej kreatywne i niestandardowe techniki, które zespół odbierze jako infantylne i niepoważne. Do tej pory preferowali zwyczajnie porozmawiać co wyszło, co nie wyszło, a nie „bawić się” w jakieś „zabawy”. Ponieważ dołączanie do nowego zespołu wiąże się często z dużym stresem i niepewnością, co słyszymy w pytaniach, jakie dostajemy podczas rozmów ze Scrum Masterami, może być też tak, że ten stres wyrwie się Tobie spod kontroli, gdy np. zespół zareaguje inaczej, niż przewidujesz. Ten stres będzie się spiętrzać i wpływać na to, jak działasz i jak się komunikujesz. Stąd też tak ważne jest przygotowanie się na te nowe okoliczności zawodowe. Jak dobrze przejść proces wchodzenia do nowego Zespołu Scrumowego? Dokonaj autorefleksji pracy w roli SM w poprzednim zespole Proces przygotowywania się do wkroczenia do nowego zespołu należy rozpocząć w swoim poprzednim zespole. Osobiście zawsze sugerujemy poświęcenie trochę czasu na porządną refleksję nad swoją pracą wykonaną do tej pory. Warto poprosić zespół o wsparcie w tej kwestii i przekazanie feedbacku, co im się podobało w Twojej pracy, a co nie i co warto poprawić. Oczywiście zdajemy sobie sprawę, że nie zawsze jest to możliwe, bo czasem rozstajesz się z zespołem w niezbyt dobrych realiach (zwolnienia, rozpad zespołu itp.). W takiej sytuacji zachęcamy do przeprowadzenia szczerej autorefleksji zgodnie z sugerowaną listą pytań autorefleksyjnych do Scrum Mastera: Jak widzę swoją współpracę z zespołem z dłuższej perspektywy czasu? Jakim zespołem byliśmy? Co chcę zmienić w swojej pracy Scrum Mastera? Co się udało, a co nie z moich planów? Jakie techniki pracy zespołowej chcę rozwijać, a które niekoniecznie? Taką au

Współpraca Scrum Mastera z Product Ownerem jest ważnym aspektem pracy w Scrumie. W tym odcinku wskazujemy, dlaczego brak współpracy może być problemem oraz podsuwamy konkretne przykłady, jak może wyglądać modelowa współpraca tych dwóch ról. Dlaczego współpraca Właściciela Produktu i Scrum Mastera jest istotnym elementem procesu zwinnego? Jakie problemy mogą się tu pojawić i jak można je rozwiązać? Temat współpracy Właściciela Produktu, czyli Product Ownera, i Scrum Mastera wydaje się prosty. Jest on również opisany w Przewodniku po Scrumie. Jednak w trakcie naszej pracy, jako Agile Coache oraz w mailach otrzymujemy wiele pytań dotyczących tego zagadnienia i w związku z tym postanowiliśmy o tym opowiedzieć więcej. Spis treści Dlaczego współpraca Właściciela Produktu i Scrum Mastera jest istotnym elementem procesu zwinnego? Jakie problemy mogą się tu pojawić i jak można je rozwiązać?Problemy wynikające z braku współpracy Product Ownera i Scrum Mastera?Jak powinna wyglądać współpraca Product Ownera ze Scrum Masterem?📄Transkrypcja podcastu „Współpraca Scrum Mastera z Product Ownerem” Problemy wynikające z braku współpracy Product Ownera i Scrum Mastera? Brak współpracy między Właścicielem Produktu a Scrum Masterem może być efektem przypadku, gdzie w sposób zupełnie niezaplanowany Product Owner nie rozmawia ze Scrum Masterem. Inny scenariusz jest taki, że ze strony Product Ownera pojawia się ignorancja dla tego, co robi Scrum Master, co może też działać w drugą stronę. W tym drugim przykładzie, siły, które mogą wspierać się wzajemnie i robić dużo dla Zespołów Scrumowych, będą się po prostu kanibalizować i nieść ze sobą straty dla całego procesu zwinnego. Ten brak współpracy może wynikać też z braku uważności i wykorzystywania okazji do rozwijania pomysłów lub sugestii drugiej strony, przez co część energii Product Ownera i część energii Scrum Mastera, które mogłyby być połączone, rozmywają się i nie dają większych korzyści mimo istniejącego na to potencjału. Nawet jeśli nie ma celowego działania przeciwko sobie czy sabotowania swoich decyzji, to nawet iluzoryczna współpraca między obiema rolami może powodować brak poczucia, że jako Zespół Scrumowy idziecie w jedną stronę. Pracując z zespołami niejednokrotnie, widzimy potencjał zarówno w teamie deweloperów, jak i potencjał w roli Scrum Mastera i Product Ownera. Wszystko jest niby w porządku, ale przez to, że nie ma tego spoiwa i współpracy pomiędzy tymi dwoma rolami, zespół często traci taką tę możliwość przemnożenia efektów swojej pracy. Jeszcze nie spotkaliśmy sprawnego zespołu, w którym ta współpraca by nie zachodziła.   Takim przykładem wzajemnego blokowania możliwości rozwoju czy wdrażania usprawnień w zespołach jest Story Mapping. Można go wykonać na bardzo podstawowym poziomie, rozkładając podróż użytkownika na serię kroków, przemyślenie możliwych opcji i wyciągnięcie z tego, takiej pierwszej wersji produktu. Jeśli jednak Scrum Master porozmawiałby wcześniej z Product Ownerem o celach biznesowych, to cały proces można by zacząć od właściwej strony, czyli od przemyślenia tego, co chcemy tak naprawdę osiągnąć.  Dla Product Ownera, który ma dobrze przygotowanie biznesowe, ale wcześniej nie pracował w środowisku zwinny, to taki brak współpracy ze Scrum Masterem jest dużą stratą w kwestii edukacyjnej. Scrum Master może go wesprzeć w doborze narzędzi, podpowiedzieć jak pracować z Backlogiem Produktu itp. Takie wskazówki mogą znacznie przyspieszyć start Product Ownera w pracy w środowisku scrumowym. Oczywiście działa to też w drugą stronę i przy partnerskim podejściu również Scrum Master może nauczyć się wiele od Product Ownera. Stąd istotne jest zbudowanie więzi i zaufania między obiema rolami.  Ostatnia rzecz, jaka nasuwa nam się w temacie problemów wynikających z braku współpracy Właściciela Produktu i Scrum Mastera jest brak wsparcia wzajemnego w promocji zwinności i wykorzystania tego zwinnego podejścia szerzej w organizacji. Wynika to z tego, że Product Owner często ma lepszy dostęp do managementu biznesowego, a Scrum Master często ma lepszy dostęp do managementu IT. Razem mają dostęp do kluczowych jednostek, a także łatwiej dostrzec im jakieś przeszkody lub lepsze rozwiązania i pomysły. Razem mają szersze spojrzenie na całą firmę. Jak powinna wyglądać współpraca Product Ownera ze Scrum Masterem? Przede wszystkim warto starać się zbudować partnerską relację. Dobrze, aby spędzali oni ze sobą więcej czasu i rozmawiali nie tylko podczas wydarzeń scrumowych, ale i poza nimi. Powinni oni czuć się swobodnie w swoim towarzystwie i wymieniać się obserwacjami, przemyśleniami i obawami. Z naszego doświadczenia, taka wymiana punktów widzenia ma pozytywny wpływ dla ich osobistego rozwoju, jak i dla efektów pracy całego zespołu. Warto, aby oboje mieli świadomość wartości płynących z partnerskiej relacji i nie wykorzystywali rozmów do budowania jakiejś swojej przewagi lub dokarmiania ego. Otwarta i szczera postawa oraz poczucie, że jesteś

Wiele produktów nie odpowiada na żadną prawdziwą potrzebę klienta, albo odpowiada w sposób niesatysfakcjonujący i z tego powodu nie odnosi sukcesu biznesowego. By zmniejszyć ryzyko braku sukcesu naszego produktu, możemy zastosować podejście Product Discovery (odkrywanie produktu). Eksplorujemy ten nurt, formułujemy możliwe etapy do zrealizowania by dobrze odkryć produkt i podpowiadamy jak zacząć stosować te techniki. Jak sprawić, aby tworzone produkty odpowiadały na prawdziwe potrzeby klienta? Jak wspomóc sukces biznesowy produktu, za który odpowiadasz? I w końcu czym jest Product Discovery i dlaczego warto wykorzystać to podejście w Twoim zespole. Spis treści Jak powstają „nieudane” produkty?Product Discovery – podejście do tworzenia produktówEtapy Product DiscoveryJak w praktyce stosować podejście Product Discovery?📄Transkrypcja podcastu „Product Discovery” Każdego roku powstaje ogrom produktów, jednak tylko nieliczne z nich odnoszą sukces biznesowy. Częstą przyczyną porażki jest nieprawidłowe podejście i brak ukierunkowania na prawdziwe potrzeby konsumentów. To ryzyko porażki produktu można zmniejszyć, stosując podejście Product Discovery, które omówimy w tym artykule. Jak powstają „nieudane” produkty? Poprzez produkt “nieudany” rozumiemy produkt, który jest po prostu niedopasowany do rynku. Nawet pomimo inwestycji w jego promocję, brak jest oczekiwanych efektów sprzedażowych.  Tego typu produkty powstają zarówno w firmach, które pracują w sposób klasyczny, jak i w tych wykorzystujących techniki zwinne. Jednym z powodów takiego stanu rzeczy jest brak znajomości realnych potrzeb użytkowników. Może się nam wydawać, że jest na rynku przestrzeń na dany typ produktu, natomiast w momencie, gdy jest on gotowy i chcemy go udostępnić potencjalnym użytkownikom, to okazuje się, że problemy lub potrzeby, które chcieliśmy zaadresować tym produktem, nie występują. Innymi słowy, ludzie go nie potrzebują.  O nieudanym produkcie mówimy również wtedy, gdy przygotowujemy błędne rozwiązania. Tu, w przeciwieństwie do wcześniejszego przykładu, dobrze rozumiemy, co jest problemem użytkowników, wiemy, jaka jest potrzebna na rynku, jednakże rozwiązanie, które dostarczamy, okazuje się niewłaściwe, np. nieintuicyjne, z dużym progiem wejścia, nie działa tak, jak oczekują tego użytkownicy.  Posługując się mniej ogólnymi przykładami, to problemem mogą być dojazdy do pracy. Konsument, codziennie pokonuje długą drogę do pracy i jego potrzebą jest skrócenie czasu dojazdu. Chętnie więc kupi produkt, który zapewni mu teleportację. To jest jego prawdziwa potrzeba, jednak sugestia, aby skorzystał z autobusu, niekoniecznie będzie dla niego rozwiązaniem problemu i zaspokojeniem potrzeby szybkiego przemieszczania się. Autobus zatrzymuje się na wielu przystankach, a w dodatku może utknąć w korku.  Przykładem rzeczywiście stworzonego rozwiązania, które nie spełnia dobrze swojej funkcji, są duże elektroniczne bilboardy na wjeździe do Poznania od strony Wrocławia. Wyświetlają one informacje o korkach, czasie oraz pokazują bardzo uproszczoną mapkę. Zapewne w zamyśle ich autorów było ułatwienie poruszania się po mieście, jednak w rzeczywistości ta mapka jest bardzo nieczytelna i dużo lepiej korzysta się z Google lub Apple Maps.  Kolejnym powodem powstawania “nieudanych” produktów jest bardzo literalne rozumienie słowa “wymagania” i odbieranie go jako coś niezmiennego, nienegocjowalnego, obowiązkowego. W takim podejściu jakiekolwiek zmniejszenie zakresu nawet jeśli stoi za tym logiczne uzasadnienie, nie wchodzi w grę i powoduje poczucie, że powstałe rozwiązanie będzie niekompletne. A z doświadczenia wiemy, że zwykle jest przestrzeń na negocjowanie tzw. wymagań i jeśli są ku temu powody, zawsze warto takie rozmowy podjąć. Product Discovery – podejście do tworzenia produktów To, co może nas uchronić przed tworzeniem “nieudanych” produktów jest podejście Product Discovery, czyli odkrywanie produktu. Nie jest to jeden, z góry sprecyzowany proces, a bardziej filozofia działania, która kładzie nacisk na zrozumienie, co jest do zrealizowania przed podjęciem jakichkolwiek innych działań wytwórczych. Przede wszystkim staramy się zrozumieć dla kogo to tworzymy, jaka to grupa ludzi, jakie ma potrzeby, czego jej potrzebuje. Innymi słowy, staramy się wejść w buty potencjalnego odbiorcy, aby mając jak najlepsze zrozumienie jego sytuacji, wejść w fazę developmentu. Nie jest to niestety częste podejście w firmach produktowych, a fokus ukierunkowany jest głównie na dostarczanie czy to wymagań, czy konkretnego pomysłu. Rynek jest jednak bezlitosny i sam weryfikuje wszystkie inicjatywy. Podkreślmy, że chodzi nam tutaj o rozwój produktu z perspektywy całego biznesu, bo wewnątrz samego IT od dawna zwraca się uwagę, aby najpierw rozpoznać, jakie są potrzeby, a dopiero potem projektować i realizować. W Product Discovery podobną filozofię przenosimy na poziom całego produktu, a nie tylko na aplikację

Czym jest Refinement Backlogu Produktu i jak go realizować w zespole, aby uzyskać jak najlepsze efekty? Dlaczego warto przeprowadzać proces doskonalenia Backlogu Produktu, zwany potocznie refinementem lub groomingiem? Jak często pracować nad Backlogiem Produktu, w jakim składzie oraz po jakie konkretne sposoby realizacji tego procesu sięgać? Poznaj nasze wskazówki i dobre praktyki. Całość podsumowujemy kilkoma praktycznymi poradami na bazie naszych własnych doświadczeń w pracy z zespołami. Jakie wątki poruszamy w tym materiale? Spis treści Czym jest Refinement Backlogu? Jak realizować Refinement Backlogu w zespole? Kto powinien brać udział w Refinemencie? Jak realizować Refinement Backlogu Produktu skutecznie? 📄Transkrypcja podcastu „Porządny Refinement Backlogu” Czym jest Refinement Backlogu? „Przewodnik po Scrumie” Refinement Backlogu Produktu definiuje jako proces dodawania elementów Backlogu produktu, uszczegółowienia ich i wyceniania oraz szeregowania rzeczy, które w Backlogu już się znajdują. Natomiast odchodząc trochę od definicji słownikowej, możemy powiedzieć, że Refinement Backlogu Produktu to po prostu proces tworzenia, rozbudowywania i ciągłego pielęgnowania Backlogu produktu. Możesz spotkać się też ze starym określeniem na Refinement Backlogu Produktu – Grooming. Ta nazwa została oficjalnie wycofana przez twórców „Przewodnika po Scrumie”, więc wspominamy o niej tylko informacyjnie. Zwróć uwagę, że Refinement Backlogu jest procesem. Oznacza to, że jest to coś ciągłego, coś co się nie kończy. Zespół w kolejnych Sprintach rozbudowuje lub rozwija Backlog Produktu. Ponadto świadomie w Scrumie nie jest dodefiniowanie, w jakiej formie ma się odbywać. Refinement Backlogu może mieć format spotkania, warsztatu, pracy indywidualnej i wielu innych czynności. Dlatego w praktyce Refinement Backlogu może wyglądać różnie w w zależności od specyfiki i przyzwyczajeń danego zespołu. Niestety z uwagi na wspomniany brak dodefiniowania, w wielu zespołach, z którymi mamy do czynienia, proces Refinementu sprawia kłopot. Nie pomaga też mit panujący w niektórych firmach, że „skoro pracujemy zwinnie, to po prostu siadamy i działamy”. Osoby działające z takim założeniem przyjmują, że dopiero w trakcie pracy wyjdzie co tak naprawdę jest do zrobienia. W najgorszej interpretacji tego nastawienia proces pracy z Backlogiem Produktu w ogóle nie zachodzi. Pierwszy moment, w którym zespół zaczyna się zastanawiać, co tak naprawdę jest w tym Backlogu, to etap Planowania Sprintu. W efekcie czas, który Zespół Scrumowy powinien przeznaczyć na zaplanowanie prac na Sprint, przeznacza w całości na nadrobienie Refinementu. Członkowie Zespołu dogadują się, o co tak naprawdę chodzi w pracy, która jest w Backlogu. Czasu na zaplanowanie Sprintu już najczęściej nie ma, przez co Sprinty kończą się kiepsko. A przecież zazwyczaj wystarczy tylko kilka godzin w skali tygodnia, aby spojrzeć w Backlog Produktu i zastanowić się, co jest do zrobienia i dlaczego jest to ważne. Spotykamy też zespoły, które nawet na Planowaniu Sprintu nie robią Refinementu. To już proszenie się o katastrofę, ponieważ wtedy członkowie Zespołu nie rozumieją rozumieją, po co coś robią, albo nie rozumieją potrzeby klienta. W rezultacie, na Przeglądzie Sprintu może się okazać, że dumnie prezentowany wynik prac jest kompletnie czym innym niż to, co było faktycznie potrzebne. Kolejnym ważnym aspektem regularnego prowadzenia Refinementu w zespole jest umożliwienie zespołowi współtworzenia produktu. Zespół ma wtedy okazję nie tylko wysłuchać Właściciela Produktu i usłyszeć co jest do zrealizowania. Dzięki zaangażowaniu się w proces tworzenia produktu Zespół może się zastanowić, jakie rozwiązania są możliwe. Ma szansę pomyśleć, jaki jest koszt różnych opcji rozwiązań. Ważnym krokiem może być też zdefiniowanie tego, jakie są kryteria akceptacji. https://youtu.be/BFK3DENvyq0 Osobiście widzimy, że zespoły, które samodzielnie odpowiadają za tworzenie i pielęgnację Backlogu produktu funkcjonują zupełnie inaczej. Są wyraźnie lepsze pod wieloma względami od zespołów, które dostają bardzo dokładnie rozpisane zadania od Product Ownera. U tych drugich zespołów brak jest współtworzenia i brania odpowiedzialności za kształtowanie produktu. Refinement Backlogu to również okazja do tego, żeby oddzielić potrzebę od możliwego rozwiązania. Użyjmy prostego przykładu z realiów rozwoju produktu cyfrowego. Product Owner mówi do Zespołu: „Zróbcie mi wyszukiwarkę na liście klientów”. Jeśli zlecający umie wyrazić swoją potrzebę przez pryzmat szczegółowego rozwiązania, pojawia się złudzenie oszczędności czasu. Zespół może natychmiast zabrać się do przygotowania żądanej wyszukiwarki. W efekcie jednak praca zajmuje np. 10 Sprintów, bo członkowie Zespołu od razu założyli realizację konkretnej funkcji. Zamiast tego mogli poszukać jakichś sprytnych rozwiązań, które w jeden lub kilka Sprintów załatwiają temat i zaspokajają albo całą potrzebę, albo znaczną jej część. Zespół ze wspom

Rozmawiamy o roli analityka oraz miejscu analizy w podejściu zwinnym. Dyskutujemy o tym, czy jest to zanikająca kompetencja, czy może nadal konieczny element procesu wytwarzania oprogramowania. Odcinek podsumowujemy dobrymi praktykami zwinnej analizy. Do czego wykorzystywana jest analiza w podejściu zwinnym? Jaka jest rola analityka w Agile i czy wciąż jest to ważny element procesu wytwarzania oprogramowania, czy może zanikająca kompetencja?  Spis treści Kim jest analityk?Jaka może być rola analityka w podejściu zwinnym?Jakie są argumenty za zmniejszającą się rolą analityka w Agile?Gdzie znaleźć miejsce dla analityka?Jak zmienia się rola analityka w Agile?📄Transkrypcja podcastu „Rola analityka w agile” Kim jest analityk? W różnych organizacjach funkcje i rola analityka mogą być rozumiane odmiennie, dlatego zacznijmy od wyjaśnienia, kogo my mamy na myśli, pisząc o “analityku”.   Najprościej rzecz ujmując to osoba, która zbiera i przygotowuje, najczęściej w formie pisemnej, wymagania związane z konkretnym produktem. Może być to analityk bardziej biznesowy, bardziej analityk wymagań czy analityk funkcjonalny, zajmujący się perspektywą potrzeb biznesu: jak to spisać, jak to przeanalizować, jak to połączyć i logicznie poukładać. Jest też taki szczebelek analizy bliżej systemu, bliżej też może Dewelopmentu i jakiejś formy architektury, jak te zebrane wymagania przełożyć na język systemu, zamodelować już jakieś procesy lub przepływ przez system. W niektórych firmach analityk jest pracownikiem najniższego szczebla, trochę takim juniorem, któremu po prostu daje się do spisania to, co jest do zrobienia w projekcie. Nie ma tam, ani profesjonalnego podejścia, ani wielkiej filozofii.  Są też firmy, w których analityka docenia się trochę mocniej i uznaje się też tą istotność tej roli. Wówczas taki  analityk ma profesjonalne narzędzia, jest dobrze przeszkolony oraz może być zgrupowany w osobny zespół. Jaka może być rola analityka w podejściu zwinnym? Są dwa podejścia odnośnie do miejsca analityka w procesie zwinnym. W pierwszym analityk pracuje samodzielnie, poza zespołem, a analiza, którą dostarcza z dużym wyprzedzeniem, jest pewnym półproduktem przekazywanym następnie do deweloperów. W drugim podejściu analityk jest częścią zespołu deweloperskiego i często oprócz wykonywania swoich obowiązków, dostarcza również nowe kompetencje całemu zespołowi. Rola analityka łatwo może kojarzyć się z podejściem waterfallowym, czyli kaskadowym, w którym najpierw mamy analizę, potem projektowanie, dewelopment i testy. Czyli można powiedzieć, że analityk jest tu sprzeczny z podejściem zwinnym, bo jest po prostu jakąś fazą przed dewelopmentem. Co więcej „Manifest zwinnego wytwarzania oprogramowania” w wielu miejscach mówi, że ten analityk nie jest potrzebny. Jakie są zatem argumenty za taką zmniejszającą się rolą analityka? Jakie są argumenty za zmniejszającą się rolą analityka w Agile? Przede wszystkim zacznijmy od tego, że ważne jest, aby zespół deweloperski był jak najbliżej problemu, który stara się rozwiązać. Ponadto, żeby zespół czuł odpowiedzialność za produkt, powinien móc uczestniczyć w różnych fazach budowania tego produktu, nie tylko w tej fazie wytwórczej. Dlatego w sytuacji, gdy analityk przejmuje od zespołu całą odpowiedzialność za wymagania, odcina zespół od bardzo ważnego aspektu, jakim jest próba zrozumienia produktu, próba zrozumienia procesów, próba zrozumienia problemu, a także ustalenia, co tak naprawdę jest do zrobienia, co jest krytyczne, a co jest mniej istotne. Przez to zespół trochę wchodzi w rolę takich podwykonawców, którzy dostają po prostu rozpisaną specyfikację i po prostu mają według niej pracować.  I to właśnie niesie za sobą ciężkie implikacje, jeśli chodzi o to, jak dalej ten konkretny zespół rozwija dany produkt. W zasadach stojących za “Manifestem Agile” jest preferencja do tego, aby komunikacja przebiegała twarzą w twarz, a nie przez przekazywane sobie dokumenty, co często ma miejsce, gdy analityk samodzielnie tworzy wymagania.  Niesie to za sobą dodatkowe ryzyko, ryzyko braku zrozumienia. Jakkolwiek by analityk nie pracował, najczęściej efektem jego pracy są jakieś spisane artefakty czy narysowane produkty, które później przekazywane są kolejnym osobom i podlegają przez nie interpretacji. A przecież owa interpretacja może być błędna, ktoś, kto to czyta, może nie złapać intencji.   Oczywiście, możemy zadbać o szczegółowe adnotacje na dokumentach, jednak Agile to przecież współpraca i rozmowa. W naszym odczuciu o wiele lepiej zadziała, gdy zespół i analitycy usiądą wspólnie do tematu i stworzą dokumentacje w czasie rozmowy. Lepiej jest też nie skupiać się na tworzeniu od razu pełnej dokumentacji, a uzupełnianie jej w czasie postępu prac. Natomiast analitycy mają często tendencję do opisywania od razu całego systemu, wszystkich walidacji, procesów czy odgałęzień. Powstaje wówczas ogromny dokument, który trudno przeczytać. I nie ma tu znaczenia fo

Moment, w którym formułowany jest Cel Sprintu dla niektórych zespołów jest kłopotliwy. Robione jest to byle jak, a cel nie jest żadnym celem tylko zakresem sprintu. Czasem tego celu zespoły nie ustalają wcale, robiąc jak co Sprint jakiś zestaw zadań wybranych z Backlogu Produktu. Na życzenie Przemka, jednego z naszych słuchaczy, pochylamy się nad tematem Celu Sprintu. Definiując go wyjaśniamy jakie są korzyści z tej praktyki. W drugiej części odcinka eksplorujemy najczęstsze pułapki wraz z propozycjami ścieżki postępowania. Mogą one pomóc Tobie i Twojemu zespołowi definiować lepsze cele co Sprint. O czym przeczytasz w tym artykule? Spis treści Czym jest Cel Sprintu?Dlaczego warto zdefiniować Cel Sprintu?Trudności z formułowaniem Celu SprintuCzego unikać przy ustalaniu Celu Sprintu?📄Transkrypcja podcastu „Cel Sprintu” Czym jest Cel Sprintu? Najprościej ujmując Cel Sprintu to jest efekt, który Zespół chce osiągnąć poprzez pracę, którą wykona w Sprincie. Zwykle jest to efekt biznesowy, związany z budowanym produktem i tym, co chcesz osiągnąć na tym konkretnym etapie rozwoju. Efekt, do którego dążysz, możesz określić jako kolejny Przyrost produktu, czyli kolejna wersja tego produktu. Czy Cel Sprintu może się zmienić w trakcie Sprintu? Warto podkreślić, że Cel Sprintu jest ustalany na Planowaniu Sprintu. Jest on stały na czas trwania Sprintu – w przeciwieństwie do planowanego zakresu. Dobrze ustalony Cel Sprintu może pomóc w przypadku niekorzystnego obrotu spraw, gdy przykładowo Zespół pomyli się co do estymat. Czasem zdarza się, że Zespół w środku Sprintu musi przeplanować swoją pracę lub przemyśleć jeszcze raz zakres. Wtedy Cel Sprintu staje się punktem odniesienia, względem którego wprowadzane są zmiany. Cel Sprintu skupia Zespół na tym, żeby na koniec Sprintu uzyskać Przyrost, niezależnie od zrealizowanych korekt w trakcie.  Z czego wynika Cel Sprintu? Dobry Cel Sprintu będzie wynikał z ustalenia, jakie są opcje rozwojowe i które są osiągalnym celem dla najbliższego kroku. Cele kolejnych Sprintów w przykładowym zespole mogą się układać w pewien szereg dalszych wersji rozwojowych: pierwsza bardzo podstawowa wersja, bez większości feature’ów, druga wersja z pierwszymi prostymi funkcjami dodatkowymi, trzecia wersja rozbudowana, czwarta wersja optimum, posiadająca wszystkie potrzebne elementy. Jakie mogą być rodzaje Celu Sprintu? Jeśli chodzi o typy Celów Sprintu, to możemy wyróżnić co najmniej kilka ich typów, ale najpopularniejsze są 2 szczególne typy: produktowy – Cel bardziej skupione na cesze lub funkcji produktu. Definiowany jest poprzez jakąś formę prostego określenia ostatecznego kształtu produktu uzyskanego po Sprincie. Przykładem może być „Dodanie nowej formy płatności w koszyku Zakupowym w sklepie online”. biznesowy – Cel skupiony bardziej na rezultacie, wyniku lub efekcie biznesowym, który Zespół chce w danym Sprincie uzyskać. Przykładem jest „Poprawa średniej wartości koszyka zakupowego w sklepie online”. W określeniu Celu Sprintu pomaga włączenie czasownika w formułę tego celu. Chodzi o to, aby konstruując cel podczas Planowania Sprintu, zastanowić się, jaki czasownik wpleść w brzmienie Celu Sprintu. Dąż do tego, żeby jak najlepiej oddać to, co Zespół chce zrobić. Przykładowe czasowniki to: „zrealizować”, „umożliwić”, „dostarczyć”, „pozwolić na…”. Wskazują one na to, co PO i Developerzy chcą zrobić. Uzupełnia się je bardziej konkretnymi wyrazami, tworząc zdanie, mówiące np. że „chcemy pozwolić użytkownikowi zalogować się przy pomocy konta Facebook”. W tym podejściu ten czasownik nakierowuje na to, jak ten Cel Sprintu zdefiniować. W powyższym przykładzie z logowaniem przez Facebooka cel biznesowy mógłby brzmieć: ‘“zwiększenie liczby użytkowników w serwisie”. Logowanie przez Facebooka może obniżyć barierę wejścia dla niektórych osób. Takich, które nie chcą zakładać nowego konta lub po prostu przez wygodę wybierają tę opcję. W ujęciu biznesowym nie jest jednak celem samym w sobie umożliwiać logowanie się, tylko dążenie do większej liczby klientów. Dlaczego warto zdefiniować Cel Sprintu? Widzimy co najmniej dwa powody, dla których warto zdefiniować sobie Cel Sprint.  Pierwszy powód jest czysto biznesowy: dobrze, aby zespół rozumiał, po co tak naprawdę wykonuje tę konkretną pracę w Sprincie. Cel Sprintu wyjaśnia, dlaczego potrzebny jest ten konkretny Przyrost produktu. Dobre zrozumienie powodów działań prowadzi do lepszych efektów i pozwala uniknąć niezrozumienia. Drugim powodem stosowania Celu Sprintu jest otwarcie pola do współdziałania całego Zespołu. Zespół będzie współpracował razem nad realizacją zdefiniowanego konkretnego celu. Praca będzie realizowane razem jako całość, a nie oddzielnie jako osobne zlecenia.  Trudności z formułowaniem Celu Sprintu Cel Sprintu niektórym Zespołom Scrumowym sprawia sporo trudności. Niektóre mają problemy ze sformułowaniem celu swojej pracy. Inne nie są do końca usatysfakcjonowane

Jakie są pułapki Retrospektywy Sprintu? Wskazujemy  te najczęściej występujące, omawiamy w jaki sposób je identyfikować oraz podpowiadamy, jak można sobie z nimi radzić.  Porządny Agile · #006 – Pułapki Retrospektywy Sprintu O tym, czym jest Retrospektywa możesz przeczytać w poprzednim artykule. Poruszaliśmy tam też problemy, jakie mogą się pojawić w związku z jej strukturą.  W tym artykule kontynuujemy temat przeprowadzania porządnej Retrospektywy Sprintu. Skupiamy się na wątkach, które wcześniej pominęliśmy lub tylko delikatnie zasygnalizowaliśmy. Opiszemy potencjalne pułapki Retrospektyw, które spotykamy w codziennej pracy z Zespołami Scrumowymi. Spis treści Skupianie się na rzeczach, które się nie udały lub są niesatysfakcjonująceOmawianie tylko miękkich tematówOmawianie tylko kwestii technicznychBrak udziału Product Ownera w RetrospektywieBrak elastyczności formuły RetrospektywyIgnorowanie tzw. „Słonia w pokoju”Wszystkie uzgodnione działania ma wykonać Scrum Master/ka📄Transkrypcja podcastu „Pułapki Retrospektywy Sprintu” Skupianie się na rzeczach, które się nie udały lub są niesatysfakcjonujące Określamy to roboczo jako “Retro żale”. Taka pułapka jest szczególnie niebezpieczna, gdy zespół całkowicie zapomina o tym, co poszło dobrze, działa i mogą być z tego dumni. Utrzymywanie się tej pułapki Retrospektywy może wykształcić w zespole trwałe poczucie, że Retrospektywa jest jednoznaczna z wytykaniem błędów. Retro kojarzy się wtedy z poruszaniem mało optymistycznych wątków i omawianiem wyłącznie niedociągnięć. Takie ryzyko często jest związane ze sposobem przeprowadzania Retrospektywy i doborem wykorzystywanych technik. Jeśli Scrum Master wartościuje obserwacje i do dyskusji wybiera tylko rzeczy do poprawy, automatycznie odcina możliwość rozmawiania o pozytywach. Przyczyną takiego podejścia może być chęć optymalizacji czasu przeznaczanego na Retro. Łatwo też o błędne założenie „skoro te rzeczy wyszły dobrze, to nie musimy o nich rozmawiać”. Z niego może wynikać skupienie się tylko na tym, co jest do usprawnienia. Duża odpowiedzialność z uniknięciem tej pułapki Retrospektywy leży w rękach moderatora, czyli osoby, która prowadzi Retrospektywę. Nawet jeśli ze strony zespołu wychodzi propozycja pominięcia rzeczy, które wyszły, to właśnie moderator powinien im uświadomić, że rozmowa o pozytywach też ma znaczenie. Za uzasadnienie takiego podejścia niech posłuży sytuacja, gdy Jacek współpracował z zespołem, który dopiero zaczynał przygodę ze Scrumem. Po dwóch tygodniach robienia regularnie Daily wszyscy zgodzili się, że to fajnie wyszło i chcieli pominąć omawianie tego. Członkowie zespołu zostali zapytani, dlaczego i z czego wynika fakt, że te spotkania miały dla nich wartość. Zaskakująco dla wszystkich zebrała się spora liczba ciekawych wniosków z różnej perspektywy. Te wnioski były istotnym czynnikiem umożliwiającym rozwój zespołu. Były zwerbalizowanymi wskazówkami, co działa, co można wykorzystać w innych aspektach pracy zespołowej w tej firmie. W ramach Retrospektywy można przecież nie tylko poprawiać rzeczy, które w zespole nie wyszły, ale także usprawniać to, co zespołowi wychodzi dobrze. Celem usprawnienia może być to, aby robić to jeszcze lepiej. To też dobry moment, aby wzmacniać poczucie, że warto eksperymentować. Nawet jeśli trzy razy z rzędu eksperymenty nie wyszły, gdy za czwartym razem coś się uda, znajdź w swoim zespole chwilę na celebrację tego i omówienie, dlaczego tym razem się udało. To jest naprawdę dobre paliwo dodające odwagi do próbowania nowych podejść w kolejnych Sprintach. Dyskusja o tym, co wyszło dobrze, to też szansa dla introwertyków. Zazwyczaj są oni mniej otwarci na rozmowy i trudniej im przychodzi zabieranie głosu. O wiele prościej mówić o pozytywach, niż o tym co jest mniej przyjemne. Odpowiednie pokierowanie tematami sprawie, że również oni będą bardziej chętni do aktywnego udziału w spotkaniach. Omawianie tylko miękkich tematów Mówiąc o tematach miękkich mamy na myśli tematy związane z komunikacją, współpracą i z tym, jak się członkom zespołu pracuje. Istotą pułapki jest to, że kompletnie pominięte są aspekty techniczne i procesowe. Spotkaliśmy się z kilkoma tezami dotyczącymi przyczyn występowania takiej pułapki Retrospektywy. Pierwszą z nich jest to, że Retrospektywa kojarzy się ze spotkaniami coachingowymi, podczas których zadawane są pytania o charakterze psychologicznym. Rozmowy kierują się w stronę naszych motywacji, relacji międzyludzkich i uczuć. Są to ważne kwestie, które również powinny pojawiać się na Retrospektywie, jednak nie powinny one zdominować całego spotkania. Powinno się też znaleźć miejsce na rozmowy o jakości kodu, środowiskach testowych czy wykorzystywanych narzędziach.  Na to, że na Retrospektywie dominują miękkie tematy, może też mieć wpływ osoba moderatora, która nie ma doświadczenia technicznego. Wspominaliśmy o tym w naszym pierwszym materiale “Kto to jest Scrum Master i czym się zajmuje”. Osobę, któ

Jeśli mielibyśmy robić tylko jedno wydarzenie scrumowe w zespole, robilibyśmy Retrospektywę. W tym materiale definiujemy, czym jest porządna retrospektywa Sprintu i jak może wyglądać jej właściwa struktura oraz przestrzegamy przed kilkoma niedociągnięciami, jakie często spotykamy. Jednym z wydarzeń Scruma jest Retrospektywa Sprintu. Ma ona ogromne znaczenie dla pracy Zespołu Scrumowego, a to, jak poważnie do niej zespół podchodzi wpływa na proces usprawniania ich pracy. Spis treści Czym jest Retrospektywa Sprintu?Jak przeprowadzić porządną Retrospektywę Sprintu?Ile powinna trwać Retrospektywa Sprintu?📄Transkrypcja nagrania „Porządna Retrospektywa Sprintu” Czym jest Retrospektywa Sprintu? Retrospektywa Sprintu jako praktyka ma swoje korzenie w ostatniej z „Zasad stojących za Manifestem Zwinnego Wytwarzania Oprogramowania”, mówiącej o tym, że zespoły w trybie ciągłym usprawniają swój proces pracy. Retrospektywa Sprintu – definicja Retrospektywa Sprintu jest regularną okazją dla Zespołu Scrumowego do porozmawiania na temat tego, jak może usprawnić on swój proces pracy we wszystkich możliwych aspektach. Istotne jest też to, by usprawnianie pracy realizować jako zespół profesjonalistów, którzy wspólnie odpowiadają za dostarczanie wartości biznesowej w jak najbardziej efektywny sposób. Dobry Zespół Scrumowy ciągle poszukuje coraz lepszych sposobów swojej pracy, ciągle się uczy i próbuje usprawniać swoje procesy. Definiując Retrospektywę Sprintu z perspektywy Scruma warto podkreślić, że jest to wydarzenie, które następuje po każdym Przeglądzie Sprintu i kończy cały Sprint. Cały Zespół Scrumowy (Developerzy, Scrum Master i Product Owner) rozmawiają o tym, jakie są możliwe usprawnienia, wnioskując na bazie wykonanego Przyrostu i zakończonego Sprintu. Poprzez retro Zespół dokonuje inspekcji i adaptacji procesu swojej pracy. Kiedy i jak często odbywa się Retrospektywa Sprintu? Bardzo istotne jest to, by podkreślić moment przeprowadzania retro. Retrospektywa Sprintu powinna kończyć każdy Sprint. Jednym z popularnych antywzorców jest pomijanie tego wydarzenia i płynne przejście od przeglądu poprzedniego Sprintu do planowania kolejnego Sprintu. Dzieje się tak, zwłaszcza gdy Zespół skupia się na przeglądaniu zadań w Backlogu Sprintu i spontanicznie zaczyna rozmawiać (ze sobą lub z interesariuszami) o kolejnych możliwych zmianach w produkcie. Oczywiście taka płynność w dyskusji po Sprincie nie przekreśla wdrożenia nowych usprawnień, jednak rekomendujemy domknięcie jednego Sprintu przed rozpoczęciem planowania kolejnego i rozdzielenie tych aktywności wyraźnie zaznaczonym spotkaniem usprawnieniowym. Dzięki temu Zespół nie pominie refleksji nad tym, które aspekty pracy chce usprawnić lub jakie eksperymenty rozpocząć. Retrospektywa Sprintu powinna się odbyć przed Planowaniem kolejnego Sprintu, ponieważ wyniki ustaleń (decyzje lub działania usprawnieniowe) mogą mieć duży wpływ na plan kolejnego Sprintu. Przedostatnia wersja Scrum Guide (przed aktualizacją Scruma z 2020) bardzo wprost rekomendowała, by z każdej Retrospektywy wynikało przynajmniej jedno usprawnienie. W wielu przypadkach może to oznaczać pracę do wykonania, którą należy umieścić w planie kolejnego Sprintu. Czy można działać Scrumem bez Retrospektywy Sprintu? Jeśli sami mielibyśmy wybrać tylko jedno wydarzenie w Scrumie, które możemy przeprowadzić, to byłaby to właśnie Retrospektywa Sprintu. Uważamy, że bez przeprowadzenia procesu usprawniania pracy Zespołu Scrumowego straci jeden z fundamentów zwinności. W takiej sytuacji istnieje zagrożenie, że zespół będzie działać miesiącami, a nawet latami bez żadnych ulepszeń, powtarzając te same błędy i tracąc okazję do zmian. Widzieliśmy sporo zespołów, które próbowały wybierać niektóre elementy Scruma. Zdecydowanie możemy powiedzieć, że jeśli zespół tworzy regularnie Przyrost i organizuje sobie Retrospektywę po zrealizowaniu tego przyrostu, istnieje duża szansa, że cała reszta Scruma wyłoni się mu automatycznie. Jak przeprowadzić porządną Retrospektywę Sprintu? Co ma wpływ na skuteczne przeprowadzenie Retrospektywy? Co zrobić, aby Zespół chciał uczestniczyć w tych spotkaniach i aktywnie brał w nich udział, wierząc w ich sens i zasadność? Struktura Retrospektywy Sprintu Przede wszystkim zadbaj o strukturę Retrospektywy, czyli sposób, w jaki spotkanie jest realizowane Jeśli prowadzisz retro, pilnuj, aby czas poświęcony na Retrospektywę nie przerodził się w planowanie kolejnego Sprintu lub dyskusję o pomysłach na zmiany w Przyroście. Spotkanie to nie powinno mieć formy luźnej pogadanki, bez konkretnego pomysłu na jej przebieg. Warto ustalić kto rozpoczyna spotkanie (zwykle jest to Scrum Master), jaka jest zastosowana technika dochodzenia do przemyśleń i ustaleń oraz zapewnić możliwość aktywnego udziału każdego uczestnika. Dobrym przykładem struktury jest ta zaproponowana przez Esther Derby w książce „Agile Retrospectives”. 5 kroków Retrospektywy Sprintu wg książki „Agile Retrospectives&#82

Kuba na konferencji Agile By Example (edycja 2018) opowiedział o tym, że „Transformacja to nie krok ani projekt, tylko niekończąca się historia”. Na bazie tamtej treści poszerzamy wątek i opowiadamy o tym, dlaczego transformacja zwinna to złożona zmiana, kto za nią odpowiada i jakie praktyki zmiany mogą być naszym zdaniem dobrym pomysłem. Czym jest, a czym nie jest zwinna transformacja – poniżej znajdziesz spis treści tego materiału. Spis treści Czym jest zwinna transformacja?Na jakie obszary wpływa zwinna transformacja?Transformacja agile – co pływa na jej złożoność?Rola Scrum Mastera i lidera a transformacja agileTransformacja zwinna – nasze wskazówki📄Transkrypcja podcastu „Zwinna transformacja to niekończący się proces” Czym jest zwinna transformacja?Transformacja jest złożoną zmianą, w której istnieją rzeczy, których osoby ją prowadzące nie są w stanie zaplanować. Ponieważ zmiana jest złożona nie jest też możliwe – zwłaszcza przed rozpoczęciem zmiany – sformułowanie ciągu przyczynowo-skutkowego, który zagwarantuje jej sukces.W wielu organizacjach transformacja jest postrzegana jako coś prostszego. Uważa się ją za projekt, który ma określony początek, koniec i spodziewany rezultat pracy.Można powiedzieć, że transformacja bywa postrzegana jak zmiana podobna do przeprowadzki. Wydaje się, że trzeba rozplanować jak zapakowanie rzeczy do przeniesienia, przewidzieć docelowy sposób rozstawienia mebli w miejscu docelowym. Innymi słowy, trzeba zidentyfikować cały zakres zmiany, później zaplanować te zmiany i je wykonać. Wiele firm świętuje zakończenie zmiany, gdy organizacja ma już nowe struktury, nowe metody pracy, a ludzie pracują na stanowiskach z nowymi etykietami. Transformacja zwinna to coś o wiele większego. Przede wszystkim bardzo wątpliwa jest możliwość zidentyfikowania całego zakresu zmiany. Ma to znaczenie o tyle, że w czasie pracy nad zmianą pojawia się cała masa nieprzewidzianych okoliczności, które mogą mocno wpłynąć na pierwotnie ustalony plan.Pułapką jest też postrzeganie transformacji jak czegoś, co się zaraz skończy. Nawet jak skończą się pierwsze zmiany związane z reorganizacją, to już same one przyczynią się do powstania pomysłów na nowe usprawnienia i idące wraz z nimi kolejne reorganizacje. Można powiedzieć, że transformacja zwinna to niekończący się ciąg zmian. I jest to całkowicie naturalne, bo zawsze można coś zmienić, aby pracowało się trochę lepiej. Zadaniem liderów organizacji jest podjęcie nowych kroków, żeby się w tej rzeczywistości odnaleźć i kontynuować drogę do osiągnięcia zamierzonych celów.Na jakie obszary wpływa zwinna transformacja? Z naszego doświadczenia wynika, że transformacja zwinna wiąże się ze zmianami w takich obszarach jak:Zmiana sposobu organizacji zespołuZmiany w procesie wytwórczymZmiany w obszarze HRZmiany w umowach z klientamiZmiany w funkcjonowania działu sprzedażySposób myślenia i pracy menedżerówPoniżej opisujemy szerzej możliwe zmiany w każdym z tych aspektów. 1. Zmiana sposobu organizacji zespołuCzęsto obserwujemy, że częścią transformacji jest zmianę podejścia do sposobu tworzenia zespołów. Firmy przechodzą z modelu skupionego mocno na projektach na podejście zbudowania zespołów odpowiedzialnych za produkty. W tym pierwszym przypadku zespoły powoływane są na czas trwania projektu. Ich członkowie często nie mają wszystkich potrzebnych kompetencji do wytworzenia produktu. Celem transformacji jest tu doprowadzenie do zbudowania zespołów zorganizowanych wokół produktu czy jego konkretnego obszaru, aby były one w stanie wytwarzać gotowe produkty w postaci ukończonych Przyrostów tworzonych nie rzadziej niż na koniec Sprintu.Jednocześnie taka zwinna transformacja to też zmiana na poziomie ludzkim. Ewolucji podlega to, jak członkowie zespołów współpracują ze sobą, jak dobrze się komunikują, ile o sobie wiedzą i kto może komu pomóc w razie potrzeby. Nawet jeśli ten aspekt dobrze wygląda w danej firmie, to reorganizacja zespołów na bardziej produktowe nadal może dać pozytywne zmiany w sferze międzyludzkiej.2. Zmiany w procesie deweloperskimTransformacja często uwypukla niedoskonałości i problemy w obszarze wytwarzania. Może się okazać, że w danej organizacji potrzeba wprowadzić zarówno nowe narzędzia związane z wdrażaniem produktu, jego testowaniem, czy z automatyzacją tych procesów. Z obserwacji wiemy, że to może być niezbędne, żeby transformacja miała w ogóle miejsce albo żeby uzyskać niezbędne efekty. Tak jak w poprzednim punkcie, mamy tu do czynienia zarówno z aspektem organizacyjnym (poukładanie procesów), jak i ludzkim (nauczenie się nowych narzędzi i sposobu pracy).3. Zmiany w obszarze HRZwykle okazuje się, że zespoły deweloperskie pracujące zwinnie potrzebują nieco innego profilu członka zespołu, niż w przypadku podejścia klasycznego. W zespołach zwinnych potrzebny jest o wiele większy zasób umiejętności komunikacyjnych, w tym empatii, czy umiejętność udzielania i przyjmowania informacji zwrotnej. Zmienić się też moż

W tym odcinku podkastu dzielimy się refleksją, jak wygląda aktualny stan zwinności w Polsce, zainspirowani artykułem Martina Fowlera „The State of Agile Software in 2018„. Na bazie naszych doświadczeń, komentujemy postępującą komercjalizację zwinności, rolę doskonałości technicznej w byciu zwinnym oraz główne różnice w pracy produktowej i projektowej. Zobacz wersję wideo Dodatkowe materiały Wystąpienie Marina Fowlera – „The State of Agile Software in 2018” (video) Transkrypcja wystąpienia Martina Fowlera – „The State of Agile Software in 2018” (tekst) Wartości oraz zasady Manifestu Zwinnego Wytwarzania Oprogramowania 📄Transkrypcja podcastu "Stan agile w 2018 roku" Poniżej znajdziesz pełny zapis rozmowy z tego odcinka podcastu „Porządny Agile”.Jacek: W dzisiejszym odcinku chcemy spróbować z Kubą trochę innej formuły niż zazwyczaj. chcielibyśmy porozmawiać, właściwie skomentować tak naprawdę bardzo wartościowe wystąpienie Martina Fawlera które nazywa się „ The State of Agile Software in 2018 ”.Chcielibyśmy podzielić się naszymi refleksjami , naszym spojrzeniem na tematy które w swojej prezentacji poruszył Martin. Kuba: Obaj, do tego wystąpienia dotarliśmy poprzez transkrypcję na stronie Martina. W podpisie odcinka jest link do tej treści. Nie chcemy w samym odcinku opowiadać co jest w treści, po prostu zachęcamy do tego, żeby to przeczytać jeśli jeszcze tego nie zrobiłeś. Natomiast chcemy skomentować i nawiązać do wątków, które Martin poruszył. Faktycznie uznajemy je za istotne i godne tego, żeby trochę się w nie zagłębić. Jacek: Trzy główne tematy, które poruszył to są przede wszystkim Agile Industrial Complex, czyli temat tego, w jaki sposób aktualnie dzisiaj Agile jest implementowany, używany, wdrażany i wykorzystywany w firmach. Drugim dużym obszarem to jest obszar doskonałości technicznej, czyli w jaki sposób Agile powiązany jest z tym jak deweloupujemy software i w jaki sposób. Trzeci ostatni temat dotyczy różnicy między orientacją pracy wokół projektów a orientacją pacy wokół produktów. Kuba: Zacznijmy od tego co nazwane tutaj zostało Agile Industrial Complex. To jest dosyć pojemne hasło. Z jednej strony Martin tam mocno porusza wątek rozwoju tej branży, czy tej dziedziny związanej z tym jak Agile jest wspierany, jak jest rozwijany, jak jest uczony. Tutaj jest wątek, powiedzmy, całego biznesu, jaki się zrodził w dziedzinie, która na początku była raczej domeną kilku autorów książek, raczej takich mniejszych consultingów. Teraz jest to po prostu gigantyczny ogólnoświatowy biznes. Jest też jakby druga strona, czy druga noga tego samego wątku. To też jest coś takiego, że coś, co pierwotnie było raczej pewną filozofią, pewnym nurtem, pewnym nowym spojrzeniem na rozwój oprogramowania, zamieniło się przez bieg ostatnich lat w coś, co jest procesem pracy. Procesem przez Martina wręcz mocno nazywanym procesem, którym zajęli się kierownicy projektów i zastąpili stare metody zarządzania projektami nowymi metodami zarządzania projektami. Chcemy poruszyć oba te wątki. Myślę, że nie będziemy się za mocno skupiać na tym wątku Agile’a jako biznesu, ale od tego chcemy zacząć. Jacek: Tak, generalnie jak tak słuchałem tego co opowiadasz to myślę, że z jednej strony żyjemy w fajnych czasach, bo dostęp do wiedzy czym jest podejście zwinne jest właściwie nieograniczony. Konferencje, spotkania sami jesteśmy teraz w drodze na Agile Coach Camp, polską edycję. Tak więc właściwie jakby się dobrze postarać to w każdy weekend czy w każdym tygodniu można znaleźć miejsce, gdzie ludzie rozmawiają o tym jak pracować zwinnie. Także dostęp do wszelkiego rodzaju publikacji jest właściwie nieograniczony. Co więcej, często bez problemu możemy dostać, w szczególności drogą elektroniczną bardzo szybko publikacje, które są w języku ojczystym. W sensie najczęściej te publikacje wychodzą po angielsku tak więc nie jest to tak jak kiedyś, że ta wiedza jest tajemna, że jest pochowana, że niewiele osób w Polsce ma dostęp do jakiejś tam publikacji czy ma jakiegoś PDFa z czymś, więc na pewno jest to pozytywny aspekt. Natomiast druga strona tego medalu jest taka, że faktycznie to pojęcie zwinności trochę się „wyświechtało”, że tak powiem. Właściwie dzisiaj kogo by nie zapytać, to pracuje w zwinny sposób i właściwie nie ma firm, które by nie deklarowały, że 'tak, używamy Scruma, tak pracujemy zwinnie”. Właściwie nie ma się do czego przyczepić. Kuba: Tu jest taka moja osobista myśl, ale Jacek pewnie masz identyczne doświadczenie, że raptem w parę lat jesteśmy w stanie zaobserwować coś takiego, że Agile gdzieś tam się dopiero w Polsce zaczynał, na początku tej dekady, a po paru latach to jest w miarę oczywiste, że we wszystkich firmach IT ten Agile jest i coraz bardziej się popularyzuje poza IT. Sporo takich wątków Agile’a poza IT, Agile’a w biznesie, Agile’a do projektów niesoftware’owych, to jest temat bardzo modny. Czaimy się, czaimy, ale ja to powiem wprost. Teraz niby jest moda, niby jest popularność

Ten materiał poświęciliśmy w całości tematowi możliwych działań rozwojowych, po to by Scrum Master stał się jeszcze lepszym w tym co robi. Na bazie swojej praktyki w roli SMa i doświadczeń we wspieraniu rozwoju Scrum Masterów jako Agile Coache przedstawiamy w sumie 7 pomysłów, które uznajemy za najważniejsze jako inspiracje do rozwoju. Jak rozwijać się w roli Scrum Mastera? Sprawdź co proponujemy: Spis treści 1. Poznaj bardzo dobrze podstawy Scruma2. Wchodź w różne role, inne niż Scrum Master3. Szukaj możliwości rozwoju jako Scrum Master w kolejnych firmach4. Poznaj inne osoby pracujące z zespołami zwinnymi jako Scrum Master5. Obserwuj dobre wzorce6. Znajdź mentora7. Zostań mentorem/mentorką📄Transkrypcja podcastu „Jak się rozwijać w roli Scrum Mastera?” W kolejnych rozdziałach poszerzamy każdy ze wskazanych pomysłów. 1. Poznaj bardzo dobrze podstawy Scruma Każdy Scrum Master powinien ciągle wracać do podstaw Scruma tak, aby mieć je w tzw. „małym paluszku”. Te podstawy możesz czerpać ze “Scrum Guide”, jednak pamiętaj, że nie chodzi o to, aby zacytować ten podręcznik na wyrywki. Ważne jest to, aby zrozumieć podstawową intencję i sens, dlaczego w “Scrum Guide” pewne rzeczy są wyrażone tak, a nie inaczej. “Scrum Guide” jest efektem ciągłego doskonalenia przedstawienia metody i jej sedna w jak najprostszy sposób. Rozwijając się, Scrum Master musi tę prostotę, a zarazem uniwersalność metody, odkrywać. Musi zauważyć, że przykładowo na początku zbyt wąsko lub zbyt szeroko zinterpretował artefakt jakim jest Product Backlog i to w efekcie może potem prowadzić do nieprawidłowego stosowania Scruma w zespołach takiego Scrum Mastera. Oprócz wracania do “Scrum Guide”, warto odświeżać sobie wiedzę, uczestnicząc w jakimś szkoleniu ze Scruma. Mając już doświadczenie w pracy jako Scrum Master, będziesz mieć inne spojrzenie na pewne zagadnienia, może odkryjesz coś nowego, wymienisz się doświadczeniami, zobaczysz, jak podobne do Twoich problemy rozwiązują inni. Sami zauważamy, że wracając do podstaw Scruma, jesteśmy w stanie dostrzec rzeczy, na które wcześniej nie zwracaliśmy uwagi, a są dla nas obecnie kluczowe. Zresztą Scrum cały czas trochę ewoluuje, powstają uaktualnienia przewodnika czy pewne elementy zostają przedefiniowane, jak chociażby ostatnie zmiany w podejściu do Daily Scrum. To jest tak, jak z wszystkimi innymi obszarami. Każde nowe doświadczenie daje nowe perspektywy, co po jakimś czasie powoduje, że skupiasz się na innych aspektach niż poprzednio. Szczególnie polecamy przeczytać na początku drogi Scrum Mastera (i wracać co jakiś czas do nich): “Coaching Agile Teams” Lyssy Adkins, “Agile and Iterative Development” Craig Larman – uczy podstaw pracy iteracyjnej oraz pokazuje czym się różni podejście kaskadowe od pracy w modelu przyrostowym, „Agile Product Management with Scrum” Roman Pichler, dosyć skondensowana wiedza o podstawach Scruma, która skupia się też na perspektywie Product Ownera i współpracy z nim. Dużo w niej przykładów, praktyk i materiałów dostępnych online. 2. Wchodź w różne role, inne niż Scrum Master Każda z nowych ról pozwala spojrzeć na proces wytwarzania produktów z innej perspektywy. Przykładowo Jacek początkowo był deweloperem i przez 7 lat programował, potem był Project Managerem, by następnie wejść w rolę Agile Coacha, znów w rolę menedżerską i wrócić do Agile Coacha. Praca jako programista pozwoliła mu doświadczyć, jak wygląda proces wytwarzania produktu od podszewki i ile pracy to wymaga, aby produkt działał. Teraz rola programisty pozwala mu lepiej porozumiewać się z zespołami, jeśli wchodzą w wątki techniczne, bo rozumie słownictwo i specyfikę pracy. Z kolei bycie Project Managerem ułatwia obecnie komunikować się z osobami, które są bliższe klasycznemu zarządzaniu projektami. Poznanie różnych perspektyw w historii kariery zawodowej jest naprawdę mocną stroną Scrum Mastera. W momencie, gdy już zostaniesz Scrum Masterem, warto wychodzić czasem z tej roli albo przynajmniej zmieniać zespoły, które są odpowiedzialne za odrębne obszary. Fajnie robić to w ramach tej samej organizacji, choć zmiana firmy też ma swoje zalety, zwłaszcza jeśli np. przechodzimy z firmy produktowej, w której pracujemy dla klienta wewnętrznego, do firmy takiej jak Software house, pracującej z klientami zewnętrznymi. 3. Szukaj możliwości rozwoju jako Scrum Master w kolejnych firmach Nie bój się zmian. Każda nowa firma czy nowy zespół, to inny kontekst projektu, inny model biznesowy czy model współpracy, inna kultura organizacji, może nawet inny typ klienta. Scrum tutaj się nie zmieni, ale zmienią się techniki pracy, ludzie i wcześniej wspomniany kontekst. Zaczynając rozumieć te różnice, ulepszasz swoje umiejętności przekonywania, dobierania praktyk i współpracy z innymi. Taka zmiana może nie być prostą decyzją, zwłaszcza jeśli budujesz relacje z osobami w twojej obecnej organizacji i przyzwyczajasz się do danych realiów. Warto jednak podjąć ten krok, bo jest to bardzo odświeżające i r

W pierwszym odcinku naszego podcastu przedstawiamy rolę Scrum Mastera. Definiujemy kim jest Scrum Master, opowiadamy jak wygląda dzień Scrum Mastera i podpowiadamy kilka najważniejszych kroków jak Scrum Master może się rozwijać, by stać się lepszym profesjonalistą. Za sukces projektów scrumowych w dużej mierze odpowiada Scrum Master. Dowiedz się, kim jest Scrum Master, jak wygląda jego praca, a jeśli pełnisz tę funkcję, to podpowiemy Ci jak stać się jeszcze lepszym profesjonalistą. Kto to jest Scrum Master? Zgodnie z definicjami z przewodników po Scrumie, Scrum Master to lider służebny, osoba odpowiedzialna za sprawne działanie zespołu i pomagająca usuwać wszelkie przeszkody, na które może natrafić zespół. Bardzo często jego funkcja kojarzona jest tylko z moderowaniem spotkań, co mocno umniejsza jego roli i prowadzi do stwierdzenia, że może nim zostać każdy w ramach dodatkowych obowiązków. Zdarza się też tak, że kojarzony jest on osobą, która pilnuje, aby rzeczy się działy i jego rola przypomina Project Managera, co jest również błędnym przekonaniem.Mówiąc najprościej, Scrum Master to osoba, która powoduje, że zarówno na poziomie zespołu, jak i na poziomie firmy, zaczynają się dziać widoczne zmiany. Innymi słowy, to taki “uruchamiacz zmian”. Potwierdza to fakt, że często w firmach, gdzie nie ma roli Scrum Mastera, zespoły stoją w miejscu i nie ma żadnych usprawnień, a te same błędy powielane są przez miesiące czy lata. Na czym polega praca Scrum Mastera? Na początku Scrum Master pomaga zrozumieć, na czym polega praca w sposób zwinny zgodny z frameworkiem Scruma. Potem, po wdrożeniu takich podstawowych ram, uruchamia procesy samodzielności w zespole. Można powiedzieć, że przechodzi z trybu nauczyciela przez tryb konsultanta, który jeszcze wciąż podpowiada pewne rozwiązania, aż po wejście w tryb pracy coacha, który sprawia, że sam zespół samodzielnie robi pewne rzeczy lub cała organizacja uruchamia pewne działania zaszyte w Scrumie. Nie jest to proste zadanie, gdyż każdy z tych trybów jest skomplikowany i wymaga doświadczenia, a co dopiero umiejętność płynnego poruszania się w tych trybach.Oprócz 3-stopniowego trybu wyróżniamy też 3 poziomy, w których pracuje Scrum Master: zespół deweloperski, Product Owner i organizacja. Proporcje pracy między tymi 3 obszarami różnią się w zależności od organizacji. Przykładowo w organizacji, w której produkt ma się dobrze, ale firma boryka się z od lat nierozwiązanymi problemami, to skupienie Scrum Mastera będzie musiało być nieco bardziej przesunięte w stronę organizacji. Istotne jest też, aby Scrum Master był wzorem transparentności wszystkich podejmowanych przez siebie działań i pomysłów, tak aby zespół wiedział czym Scrum Master się zajmuje, o co się stara i ile wysiłku wkłada w swoją pracę. Może on np. opowiedzieć po codziennym Scrumie, nad czym obecnie pracuje, co się dzieje i co może zainteresować developerów.Jawne przedstawianie swoich intencji ułatwi Scrum Masterowi pracę, gdyż chcąc wprowadzić do zespołu nowe rozwiązania czy konkretne praktyki, będzie mu łatwiej to zrobić, przedstawiając powody zaproponowanych zmian. Nie będzie musiał tego robić “na siłę”, a zrozumienie przez zespół powodów jego działań może dodatkowo zostać nagrodzone wsparciem i otwartością na dyskusje wewnątrz zespołu.Warto podkreślić też, że Scrum Master nie musi sam zastanawiać się jak rozwiązać konkretne problemy w zespole. Dobrą zasadą jest zasada z książki „Coaching Agile Teams” Lyssy Adkins brzmiąca “Take it to the team”. Czyli Scrum Master powinien umieć nazwać dany problem, jasno przedstawić go w zespole, a następnie tak poprowadzić dyskusję, aby na końcu spotkania mieć konkretne kroki do wykonania. Ponadto, z naszego doświadczenia wynika, że im bardziej zespół będzie zaangażowany w generowanie tych rozwiązań, tym większa jest szansa, że te rzeczy faktycznie zostaną zaimplementowane. Członkowie zespołu będą mieli poczucie sprawczości i większej odpowiedzialności.Drugą dobrą zasadą w pracy Scrum Mastera jest zasada, w której pozwalamy zespołowi testować własne pomysły, nawet jeśli mamy świadomość, że są one z góry skazane na niepowodzenia. Przykładowo, jeśli zespół stwierdza, że nie chce robić codziennego Daily Scruma, to pozwólmy im na to, zróbmy eksperyment w ramach jednego Sprintu i zadbajmy o to, aby wyciągnąć potem odpowiednie wnioski. Rolą Scrum Mastera jest przecież dbanie o to, aby zespół ciągle szukał usprawnień, aby zespół był zaangażowany, w to jak pracuje, a nie pilnował sztywnych reguł i podstaw teoretycznych. Po takim eksperymencie, w którym zespół porzuci na chwilę Daily Scruma, zrozumie, po co im te codzienne spotkania i będzie w nich bardziej świadomie uczestniczył. To może być trudne do uzyskania, jeśli Scrum Master zabroni eksperymentu, będzie zmuszał do spotkań, bo on przecież wie lepiej. Jak wygląda dzień Scrum Mastera w pracy? Ponieważ wszystko zależy od organizacji w jakiej pracujemy, poziomu zespołu oraz dojrzałości produktowej w firmie, dzień pracy Scrum Mastera