Video

Mam podobne wyzwanie w zespole, ludzie chyba z natury nie lubią brać odpowiedzialność za swoje działania. Ty zrób a my pomarudzimy że to do kitu :)

Potrzebowałem tego filmiku i utożsamiam się z nim w pełni. Osoby w moich zespołach w większości wywodzą się z czasów, w których projekty były realizowane metodykami kaskadowymi i widzę, że nie czują samoorganizowania się. O ile cześć zespołu odpowiedzialna za QA jak najbardziej chce i potrafi to robić to o tyle developerska część ma ciągłe myślenie, że jak coś nie jest przypisane do nich do realizacji (konkretnej osoby) to nie musi tego robić i oczekują ode mnie bym im te zadania przypisywał. Dochodzi przez to do kuriozalnych sytuacji, w których mimo listy zadań na sprintach developerzy po skończeniu tego co mieli przypisane siedzą i czekają na "przypisanie" im kolejnego zadania. Próbowałem stworzyć proste filtry, które będą prezentować takie zadania, ale nie do końca umiem chyba zachęcić ich do korzystania z nich. PO także stara się jak może układając zadania w BL tak by było wiadomo co brać następne, ale chyba jeszcze długa droga przed nami by zmienić ten mindset. Tomku pytanie co w sytuacji, kiedy widać, że zespół nie jest gotowy na to, ale mimo wszystko organizacja naciska by iść w tym kierunku?

12 osób o matko jedyna mam 3 na raz i w każdym jest 12 osób

A co jak na Retro mają do SM uwagi, przerabiam sytuację gdzie jako SM dajesz zespołowi wędkę a oni ciągle rybę chcą bo im się spieszy (pressing jest zawsze)

Powinna być: - Otwarta - Angażująca - Powinna wyciągać wnioski i action pointy - Zrozumiana przez wszystkich w teamie. Te cechy się nachodzą i najważniejsze jest żeby była respektowana bo nie zawsze teamy rozumieją po co to robimy i często gęsto Ci cisi mają najciekawsze pomysły ale boją się wyjść publicznie ze swoimi pomysłami

"*****" PO 👊🥊👊...

Żeby był zapierdol xd

Zespół nie pracuje w próżni, atmosfera panująca w firmie ma ogromny wpływ, to trudniejszy czas dla rynku IT, presja, niepewność, rotacje wpływają na poziom motywacji zespołów. Motywacja strachem o swoją przyszłość to nie motywacja. Nie skupiałabym się tak kurczowoformy pracy zdalna/stacjonarna.

Gaszenie pożarów benzyną <3

Ja się nie do końca zgodzę, że kiedyś to było... 🤭. Mój zespół, mimo że zdalny, to pracuje razem. Wszyscy są zmotywowani, bo robimy fajne rzeczy. I zdalnie można fajniejsze retro zrobić, gdzie wszyscy chętnie przychodzą i też mówimy o motywacji 😉.

Moje odczucia są inne niż wasze, ale nie mam dużej próbki, bo tylko mój zespół. I w moim przypadku mam zespół, któremu się chce, który razem pracuje w prawie niezmienionym składzie już 4 lata, i wydaje mnie się też, że częściej pracujemy w parach lub grupach (bo w biurze to po prostu było niewygodne albo niemożliwe). Praca zdalna to typowy trade-off, ma plusy i minusy. Z plusów, każdy z nas ma teraz swoje własne biuro w domu, ciszę i spokój i o wiele łatwiej się spotkać w 2 lub więcej osób, bo nie trzeba szukać salki, przenosić sprzętu, wystarczy jedno kliknięcie. Innym plusem jest brak dojazdów do pracy. Z minusów to chyba najbardziej brakuje głupich rozmów w kuchni, wspólnego pójścia na obiad czy rywalizacji przy stole do piłkarzyków. :)

czcams.com/video/0jk5Sy1ibtk/video.html Na pracy zdalnej wiele się zmieniło, ale nie sądzę, że poszło to głównie w stronę "piniędzy". Inne motywatory dalej są dla ludzi ważne, ale na "zdalnej" SM powinien dbać o to, żeby zespół był zespołem, i żeby (różne) motywacje służyły temu zespołowi, a nie go niszczyły.

Ciekawy odcinek i fajnie wyjaśnione! (tylko ta końcówka jakaś ucięta bez pożegania, nie wiem czy tak miało być). Czekam na podobną tematykę w przypadku Product Ownera ;)

Ciekawy materiał, na pewno zgadzam się z grubsza ze wszystkimi tezami, a na pewno z 1, że to mógłby być dokument opisujący rolę SM (wtedy trochę skończyłyby się pomysły przypisywania SMom 4-5 zespołów, bo przecież tylko spotkania wbija w kalendarz)... :) 2 rzeczy brakło w mojej ocenie: 1. to o czym przedmówca wspomina, niestety facylitowanie, w mniemaniu wielu to modeorwanie spotkania i tyle. 2. mówiąc o coachu, jako osobie która wcześniej robiła co robi reszta, to o czym dokładnie mówicie? Bo osobiście spotykam się coraz częściej ze stwierdzeniami "techniczny" i tutaj pytanie jak "techniczny" powinien być... ale z drugiej strony widzę, że wielu SMów brak pojęcia o prowadzeniu biznesu, o rozumieniu rynku, zbierania i dokumentowania wymagań itp. Więc rodzi mi się tutaj pytanie: - czy dobry SM to ten który zna się na developerce, ale już nie na zarządzaniu zespołem, psychologią w biznesie, zbieraniu wymagań, zarządzaniu biznesem - czy to drugie, - czy wszystko na raz. Piszę powyższe aby wskazać że, pryznajmniej w mojej ocenie, jest wiele aspektów związanych z "technicznością" SM'a, I jeśli po kilku latach pracy SM nie potrafi na pewnym poziomie poruszać się swobodnie w terminologii i zrozumieniu co robi zespół, to marnie, marnie. :)

i nie zgodzę się, że facylitacja to jest taka najprostrza i banalna bo każdy to robi "i ciężko jest tego nie robić"... Pytanie czy robi to umiejętnie? Niestety z moich doświadczeń większość Scrum Masterów niestety traktuje ją jako "prowadzenie, moderowanie spotkań" i sugerowanie rozwiązań... a to zupełnie nie o to chodzi w facylitacji.

Jako SM wspieram zespół jak najbardziej kompletny, tj. decyzyjny PO, dev's, AB's, AR, eksperci biznesowi i testerzy. Wszystkie wątpliwości załatwiane "na krótko" (kanał na Teams, "kawa" po daily, itp.). Wyzwanie to ilość osób: 18 z SM :-)

Moim skromnym zdaniem "branie na siebie rzeczy, żeby ulżyć 'zespołowi'" to nie jest pomoc. To bardziej schowanie problemów i zwiększenie ryzyka, że nie zostaną rozwiązane. Jeżeli jakieś elementy zasad / procesów są durne, zabierają czas i nie dają wartości, ludzie są sfrustrowani itd. - to jesteśmy na lepszej trajektorii niż jak ten czynnik zniknie w kieszeni SMa (z którym może się upora, a może nie - w końcu teraz to tylko na jego głowie). Raczej SM powinien być iskrą jeżeli takiej potrzeba aby zauważyć i zaadresować słonia w pokoju WSPÓLNIE 🙂

Scrum Master został zastąpiony przez kompetencje PMów i seniorów w zespole, którzy potrafią ustawiać procesy w iteracyjnym modelu Agile. Aktualnie z tego co widzę jest to traktowane jako dodatkowa wiedza, czy kompetencja raczej niż osobna rola. Może ze względu na cięcia kosztów. W każdym razie bardziej widzę rolę Agile Coacha w organizacji, który ma kilka zespołów pod sobą i pomoga przeprowadzać retro, planowanie itp. niż osobę która jest codziennie na daily...

ciekawa metryka 👍 do zobaczenia w Wa-wie 🙌

Do zobaczenia na www.scrumsummit.pl/!

Widzimy się za 2 dni 😊

Mnie trochę irytuje brak scrum mastera bo te obowiązki spadają na programistów. Nigdy nie chciałam prowadzić spotkań i zespołem a muszę to robić.

Taki useless zarabia tyle pieniędzy, abstrakcja 😆🤣

Nie powiem gdzie możesz sobie wsadzić ten przester

W książkach ;)

Dobre łapy widać białko działa :)

Tu się zgadzam, scrum master musi mocno uważać by nie być blaznem

Uwaga z końcówkicelna... to jest najbardziej problematyczne.. inna sprawa, to też jak nie zwariować, i nie doktoryzować się z organizacji pracy zamiast pracować

Agile tak bardzo odbiegł od pierwotnego manifestu, że całe słownictwo jest w sumie do zaorania ;)

Trzeba znależć choćby jedną osobę w Kierownictwie przekonaną do zmiany. Należy przekonać Kierownictwo nie poprzez prezentację na czym polego SCRUM Agile, ale prezentację z przykładami jak takie podejście daje efekty dla firmy

Ciekawy odcinek, Jednak jestem z nim rozczarowany. Praktycznie do każdego punktu chciałbym dodać addendum mocno komplikujące ten temat. Po pierwsze wybacz jeśli ton tego co pisze będzie dość surowy nie jest to próba ataku na ciebie po prostu mam taki styl pisania :) Zacznę od tego że jeśli patrzylibyśmy na nazwijmy to najczęstszy przypadek to jak najbardziej się z tobą zgadzam. Oddzielny zespół byłby powrotem do czasów przerzucania się przez mur i umywania rąk. To były czasy gdzie Testerzy przez to że byli na końcu, często byli traktowani jako kozły ofiarne "bo to oni się nie wyrobili" mimo że tak jak mówisz opóźnienia był w całym procesie i przekładaniu rąk do rąk. Które sie działo nim ruchy takie Shift-Left i Agile mocno to zmieniły. Jednak ten najczęstszy przypadek nigdy nie był taki częsty, istnieje multum edge casów które czynią go nie koniecznie optymalnym rozwiązaniem dla firmy. I najczęsciej gdy widzę osobne zespoły testerskie (a jest to raczej rzadko) to jest to podyktowań tego typu edge casami. Oczywiście znam trochę przypadków gdzie firma ma zespół testerski bo zatrzymała sie w latach 80siatych i waterfall to dla szczyt rozwoju procesów. A mianowicie od lat ten "najczęstszy" przypadek staje sie coraz rzadszy - Testera jako roli na świecie jest coraz mniej i często testowanie jest obecnie traktowane jako aktywność developerska która nie wymaga osobnej roli. Zahaczyłeś o niego ok 20:40 - jednak z tego co mówisz mam wrażenie, że nie miałeś do czynienia z firmami i zespołami gdzie to poprawnie działało. Bo właśnie "develoeprzy nie chcą testować" i "tester ma inny mindset" to są najczęstsze argumenty obok "zawsze tak robilismy i było dobrze" które używają członkiwie zespołów którzy są przeciw takim zmianą. A jednak w rzeczywistości jest on pociągniecie twojej metafory o definiton of done i kocie Schoedingera do logicznej konkluzji - bo "poco czekać jak ktoś inny w zespole mi to przetasuje skoro mogę sam" W takich wypadkach traktowanie testerów (czy raczej juz QA ) jako zespół platformowy którego celem jest dostarczanie narzędzi i know how do zespołów, czy wsparciu ich w co trudniejszych przypadkach jest praktyką która ma jak najbardziej sens. Bardzo lubię tutaj cytat z Alana Page'a jak robił transformacji w Unity "Jakie testy robią developerzy? Wszystkie, jakie potrafią zrobić." Ogólnie widzę tutaj przestrzeń na ciekawa dyskusje

Osobiście uważam że aby w na przykład w korporacji udała się zwinność potrzeba: - oddzielenie ludzi mających potencjał od zabetonowanych poprzez stworzenie oddzielnych zespołów, najlepiej z tych co chcą spróbować pracy po nowemu - te zespoły muszą w ramach korporacji mieć osobę bezpiecznik, która pozwoli im działać w nowy sposób bez większy interwencji ze strony organizacji (tu sprawdzi się project manager, który zgodzi się aby jeden zespół działał w sposób agileowy) - scrum master nie może być z przypadku tylko musi miec doswiadczenie - z czasem ktos z zespolu moze zostac scrum masterem

Bardzo fajny temat

fajne wprowadzenie do LeSSa 👍

Kate Middleton się znalazła, a Łukasz Bręk jeszcze nie... czy podzielicie się wiedzą co się z szanownym kolegą dzieje?

fajny rozmówca, słychać że praktyk. Proszę o więcej!

Najbardziej zwinnym zespołem jaki pamiętam był ten, który nie wiedział, że pracuje zwinnie :)

Zgodzę się, w pracy SM'a celem jest USPRAWNIANIE procesu, a nie na siłe powtarzanie pewnych schematów byle się ich trzymać - szczególnie jeśli nie działają lub nie dają wartości.

Fajnie byłoby obejrzeć analogiczny film z PSMIII :)

“Największym problemem w komunikacji jest iluzja, że miała ona miejsce” - używając różnych terminów używamy ich aby lepiej się porozumieć, jeżeli za nazwą/terminem nie idzie nic więcej, to tylko robimy sobie problemy. Jeżeli ktoś mówi że pracują w Scrumie, to za tym idzie szereg niewypowiedzianych założeń jakie pojawiają się u adresata takiej wiadomości, np. spodziewa się używania celu produktu, lub celu sprintu. Podobnie można powiedzieć o np. “Green washing”, można np. Na każdy wyprodukowany produkt dotować sadzenie drzew i twierdzić że nasz produkt jest eko. Czy też możemy powiedzieć, że rozwijamy AI, a pod spodem nie mieć nic z tym związanego więcej niż pseudo czatbot na stronie… Na koniec dnia wracamy do problemu z cytatu. Jeżeli nie zadbamy o język i świadome używanie terminów, to zawsze powinniśmy zaczynać od zera i ustalenia co się za każdym zwrotem kryje 🤷‍♂️

Bardzo fajny odcinek, mnie osobiście nic nie irytuje bardziej niż purystyczne podejście do Scruma i traktowanie go jako świętość :) Trochę to niestety pojawia się na rozmowach rekrutacyjnych - tj. osoby rekrutujące na siłę chcą udowodnić, że nie znam/nie stosowałem/źle stosowałem Scruma.

bardzo ważny temat

Daily Scrum powinno się robić codziennie, dlaczego bo jest to w nazwie "Daily Scrum" :D A tak poważniej to samo to, że Daily ma się odbywać w tym samym miejscu i o tym samym czasie i nie trwać dłużej niż 15 min daje nam cudowne narzędzie do tego by w sytuacji pracy zdalnej mieć te 15 min dla zespołu gdzie wszyscy się zawsze spotykają by omówić najważniejsze tematy i bolączki. Jeśli ich nie ma to wtedy daily trwa 2 min i koniec, jeśli są to adresuje się je do konkretnej grupy osób (bo zazwyczaj nie dotyczą całego zespołu) i robi się oddzielne spotkanie, na którym się je rozwiązuje. Jeśli natomiast robimy Weekly to wystawiamy się na ryzyko tego, że pracownik będzie czekać z powiedzeniem czegoś co mu utrudnia pracę do tego właśnie spotkania. Jeśli damy zespołowi do decyzji, czy chcą zrezygnować z Daily Scrum to w 90% powiedzą, że tak. Dlaczego? Bo mało kto rozumie jaki jest cel tego spotkania :) i zazwyczaj traktowane są jako spotkanie do raportowania swojej pracy, a tego nikt nie lubi robić :P A 1-2h "daily" dziennie na planowanie kolejnych 24h pracy to nie daily tylko mikro planingi.

Piękna puenta. Można po prostu nie robić Scruma. Nie udawać, nie nazywać tego "pseudo-scrumem", podnieść czoło i odważnie powiedzieć: nie pracujemy w Scrumie i to jest OK.

Powiedzieć, że Daily to planowanie na 24h / do następnego Daily to jak nic nie powiedzieć 😅 "The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work." Upraszczanie tematu też tylko do "planowania pracy" zaciemnia sens Daily w Scrumie do którego nawiązujecie. Podstawą jest skupienie na celu, nie na pracy, jeżeli ten nasz plan ulega zmianie, to powinien być to rezultat dążenia do tego aby były jak największe szanse na osiągnięcie celu. W sytuacji w której każdy z nas działa samotnie, w izolacji (ja i moje taski, etc.) to i Daily będzie sztuczne, ba weekly też może być "za często", ponieważ wcześniejszym problemem jest to, że nie jesteśmy zespołem. Najlepszą analogią do Daily (Scrum) jest koncepcja "czasu" w sportach zespołowych. W każdym sporcie (a szczególnie zespołowym) jest taki moment złapania oddechu i "replanowania" pod kątem chęci osiągnięcia celu. W piłce nożnej jest to 15min po pierwszej połowie, w Rugby 3 przerwy na połowę, w koszykówce 6 długich i 2 krótkie timeouty, czy nawet w e-sporcie (np. league of legends) do 4 przerw po max 1min. Jeżeli uznajemy, że Daily jest za często, i jedyne o czym rozmawiamy to praca wykonana / do wykonania i przeszkody do jej wykonania, to bardziej jest to oznaka tego że nie jesteśmy zespołem (być może to ok w danym kontekście), a po prostu grupą ludzi którzy czasami pracują razem 🤷🏻‍♂

Z ciekawostek o SAFe, to używa go Holenderska firma ASML do swoich zadań inżynierskich związanych z projektowaniem. Tworzą najbardziej skomplikowane maszyny świata składające się z około 100000 części (maszyna EUV), integrując w procesie tysiące dostawców.

Przyznam się - że po nazwie byłem lekko szokowany - Czemu Białko chce gadać o frontendzie? Less - to także nazwa języka do CSS - czyli do stylowania stron internetowych. A tu sie okazuje ze zbieżność nazw. - o SAFe nie raz słyszałem i za bardzo fanem nie jestem tak jakoś LeSS mnie ominął (choć mam wrażenie z pełna nazwę Large Scale Scrum kiedyś słyszałem). Będę musiał poczytać - dzięki!

Tak było ciekawie

a dla mnie fajny i wartościowy materiał.

Straszni to są ludzie. A SAFe to po prostu jest ukryty waterfall i comand &control. Nie ma w tym nic strasznego. Po prostu irytuje hipokryzja.