Sorry, ale moje doświadczenie jest takie, że jak developerzy się nie postawią w stosunku do biznesowego betonu to taki, nazwijmy, "standalone" scrum mastera obsługującego X zespołów nic nie zmieni, a posiadanie go jest takim listkiem figowym dla organizacji w stylu "no mamy scrum bo mamy SM". Dlaczego? Bo często jest zbyt daleko od zespołu (a przecież powinien być jego częścią) i nie rozumie ich problemów. Z kolei w zespołach, które mogą i chcą implementować scrum oddzielna rola dla SM jest niepotrzebna - powinien wyłonić się lider, który będzie z początku nad tym czuwać - okej, odbędzie się to kosztem zadań - ale celem jest by team sam się organizował, więc nawet jeśli nie mają wiedzy jak go implementować to właśnie dzięki temu, że scrum zostawia miejsce na samorozwój i refleksję mogą tą wiedzę z czasem posiąść. Oczywiście nie twierdzę, że nie ma wyjątków, ale takie są moje dotychczasowe doświadczenia - w firmach gdzie był zatrudniony człowiek specjalnie jako scrum master najbardziej irytujące dla developerów tematy trwały wiecznie nieruszone, bo były istotne dla klienta (tak naprawdę to były rzeczy zbędne). Oczywiście to nie tylko wina scrum mastera - dla developerów to też jest pewnego typu wymówka w stylu "a no nie jestem efektywny, bo X i Y", ale tu wracamy do początku mojej wypowiedzi: dopóki developerzy się nie postawią to nic się nie zmieni. Być może większość z tych problemów wynika z niezrozumienia różnicy pomiędzy rolą a stanowiskiem.
Być może to zbyt trywialny i podstawowy aspekt jak na Wasz zgłębiający wiele różnych szczegółów kanał, ale osobiście bardzo chętnie posłuchałbym materiału definiującego ten proces, o którym wspominacie w pierwszej połowie filmu. Czyli etap, w którym SM ma full time co robić. To znaczy konkretnie jakiego typu i rodzaju czynności mogą składać się na taką aktywność, Jakie występują zazwyczaj i z jakimi można spotkać się tylko czasami. Czyli co konkretnie robi SM, w detalu. Ciekaw jestem jak byście to opisali ze swojego doświadczenia.
Tym razem film ok, dzięki. Wyobrażam sobie SM jako element systemu identyfikujący osoby, procesy i sytuacje, które odpowiadają za blokowanie optymalnego przepływu procesu, informacji i produktu w organizacji. Przychodzi z WD40 i pryska gdzie trzeba i jak długo trzeba.
Dzięki! O Scrum Masterze nakręciliśmy wiele filmów, a jeden z najstarszych to "Kim jest Scrum Master?" - th-cam.com/video/dKvhlHXGKMo/w-d-xo.html Trochę się zestarzał i na pewno nagramy go na nowo, ale i tak powinien być dobry "na początek". Mam też tekst o tym samym tytule: bialko.eu/agile/scrum-master/
2 ปีที่แล้ว +5
Ciekawy odcinek, chociaż jak zawsze w tych tematach kłuje mnie nadużywanie terminu "efektywność" ;) Czy możecie wytłumaczyć jak ten termin rozumiecie i dlaczego jest waszym zdaniem właściwym tłumaczeniem angielskiego terminu "effectiveness" używanego w scrum guide? Osobiście uważam, że jest to błędne tłumaczenie i prawidłowo powinno się mówić o "skuteczności". To oczywiście nie oznacza, że efektywność nie powinna SM (czy kogokolwiek) interesować, wręcz przeciwnie, aczkolwiek moim skromnym zdaniem kiedy rozmawiamy o efektywności to domyślnie się zakotwiczamy na ocenianiu osiągniętych rezultatów do poniesionych nakładów (np. czasu) i skupiamy się na optymalizowaniu tych parametrów. Postawiłbym hipotezę, że nadmierne stosowanie terminologii (często bez zrozumienia) jest jedną z głównych przyczyn dlaczego w organizacjach są dziesiątki metryk na weryfikowanie ponoszonych nakładów - np. wspomniane logowanie czasu pracy, a niewiele lub w ogóle nie można spotkać metryk pomagających ocenić to czy jesteśmy skuteczni.
Wg mnie to jedno i to samo - problem leży chyba w tym, że organizacje mają zły sposób oceniania tej samej wartości, t.j. w tym raportowaniu czasu pracy nie jest zawarte ile kijowo zrobiona robota będzie kosztować wszystkich za kilka miesięcy, a tym bardziej lat.
I tutaj sie nasuwa pytanie czy scrum master skaluje swoj czas pracy czy jednak to nie jest tak ze w 80% przypadków jednak zarabia 10k i pije kawe bo dobry zespół sam wie jak ma pracować.
Widzieliśmy wiele różnych opcji - SM, który bierze kolejny zespół albo zespoły; SM, który przechodzi na 3/4 albo 1/2 etatu; ale też oczywiście SM, który pije kawę...
czy jest to stanowisko zbliżone do Traffic Managera, który działa jako elektron pomiędzy zespołami, leaderami. Układa proces, dba o raporty efektywności, roboczogodziny itp? :)
![[#9] Czy Scrum Master powinien być techniczny?](http://i.ytimg.com/vi/9Y_Jx5O_RyA/mqdefault.jpg)
![[#9] Czy Scrum Master powinien być techniczny?](/img/tr.png)
Obejrzalam i nadal nie wiem, co robi scrum master.
Może pomoże materiał z przed 4 lat: th-cam.com/video/dKvhlHXGKMo/w-d-xo.html ;)
SM odblokowuje potencjał w organizacji, identyfikuje i pomaga usuwać przeszkody pogarszające dostarczenie produktu
@@user-sl5nm9js8pczyli jaką wiedzę precyzyjnie powinien posiadać?
@@K22mah73hgpytam serio czy mówisz serio? Czy to sarkazm?
Sorry, ale moje doświadczenie jest takie, że jak developerzy się nie postawią w stosunku do biznesowego betonu to taki, nazwijmy, "standalone" scrum mastera obsługującego X zespołów nic nie zmieni, a posiadanie go jest takim listkiem figowym dla organizacji w stylu "no mamy scrum bo mamy SM". Dlaczego? Bo często jest zbyt daleko od zespołu (a przecież powinien być jego częścią) i nie rozumie ich problemów. Z kolei w zespołach, które mogą i chcą implementować scrum oddzielna rola dla SM jest niepotrzebna - powinien wyłonić się lider, który będzie z początku nad tym czuwać - okej, odbędzie się to kosztem zadań - ale celem jest by team sam się organizował, więc nawet jeśli nie mają wiedzy jak go implementować to właśnie dzięki temu, że scrum zostawia miejsce na samorozwój i refleksję mogą tą wiedzę z czasem posiąść.
Oczywiście nie twierdzę, że nie ma wyjątków, ale takie są moje dotychczasowe doświadczenia - w firmach gdzie był zatrudniony człowiek specjalnie jako scrum master najbardziej irytujące dla developerów tematy trwały wiecznie nieruszone, bo były istotne dla klienta (tak naprawdę to były rzeczy zbędne). Oczywiście to nie tylko wina scrum mastera - dla developerów to też jest pewnego typu wymówka w stylu "a no nie jestem efektywny, bo X i Y", ale tu wracamy do początku mojej wypowiedzi: dopóki developerzy się nie postawią to nic się nie zmieni.
Być może większość z tych problemów wynika z niezrozumienia różnicy pomiędzy rolą a stanowiskiem.
Być może to zbyt trywialny i podstawowy aspekt jak na Wasz zgłębiający wiele różnych szczegółów kanał, ale osobiście bardzo chętnie posłuchałbym materiału definiującego ten proces, o którym wspominacie w pierwszej połowie filmu. Czyli etap, w którym SM ma full time co robić. To znaczy konkretnie jakiego typu i rodzaju czynności mogą składać się na taką aktywność, Jakie występują zazwyczaj i z jakimi można spotkać się tylko czasami. Czyli co konkretnie robi SM, w detalu. Ciekaw jestem jak byście to opisali ze swojego doświadczenia.
Tym razem film ok, dzięki. Wyobrażam sobie SM jako element systemu identyfikujący osoby, procesy i sytuacje, które odpowiadają za blokowanie optymalnego przepływu procesu, informacji i produktu w organizacji. Przychodzi z WD40 i pryska gdzie trzeba i jak długo trzeba.
Format rozmowy na kanapie ok. Natomiast nie wytlumaczyloscie w ogóle na czym polega i czym zajmuje się Scrum Master. Pozdrawiam
Dzięki! O Scrum Masterze nakręciliśmy wiele filmów, a jeden z najstarszych to "Kim jest Scrum Master?" - th-cam.com/video/dKvhlHXGKMo/w-d-xo.html Trochę się zestarzał i na pewno nagramy go na nowo, ale i tak powinien być dobry "na początek". Mam też tekst o tym samym tytule: bialko.eu/agile/scrum-master/
Ciekawy odcinek, chociaż jak zawsze w tych tematach kłuje mnie nadużywanie terminu "efektywność" ;)
Czy możecie wytłumaczyć jak ten termin rozumiecie i dlaczego jest waszym zdaniem właściwym tłumaczeniem angielskiego terminu "effectiveness" używanego w scrum guide?
Osobiście uważam, że jest to błędne tłumaczenie i prawidłowo powinno się mówić o "skuteczności". To oczywiście nie oznacza, że efektywność nie powinna SM (czy kogokolwiek) interesować, wręcz przeciwnie, aczkolwiek moim skromnym zdaniem kiedy rozmawiamy o efektywności to domyślnie się zakotwiczamy na ocenianiu osiągniętych rezultatów do poniesionych nakładów (np. czasu) i skupiamy się na optymalizowaniu tych parametrów. Postawiłbym hipotezę, że nadmierne stosowanie terminologii (często bez zrozumienia) jest jedną z głównych przyczyn dlaczego w organizacjach są dziesiątki metryk na weryfikowanie ponoszonych nakładów - np. wspomniane logowanie czasu pracy, a niewiele lub w ogóle nie można spotkać metryk pomagających ocenić to czy jesteśmy skuteczni.
Wg mnie to jedno i to samo - problem leży chyba w tym, że organizacje mają zły sposób oceniania tej samej wartości, t.j. w tym raportowaniu czasu pracy nie jest zawarte ile kijowo zrobiona robota będzie kosztować wszystkich za kilka miesięcy, a tym bardziej lat.
I tutaj sie nasuwa pytanie czy scrum master skaluje swoj czas pracy czy jednak to nie jest tak ze w 80% przypadków jednak zarabia 10k i pije kawe bo dobry zespół sam wie jak ma pracować.
Widzieliśmy wiele różnych opcji - SM, który bierze kolejny zespół albo zespoły; SM, który przechodzi na 3/4 albo 1/2 etatu; ale też oczywiście SM, który pije kawę...
czy jest to stanowisko zbliżone do Traffic Managera, który działa jako elektron pomiędzy zespołami, leaderami. Układa proces, dba o raporty efektywności, roboczogodziny itp? :)
Oczywiście, że nie. Wyczuwamy, że to było pytanie podchwytliwe. ;)
@@bialko jestem ciekawa jak to wygląda z perspektywy ewentualnego, przyszłościowego przebranżowienia :D
o o ? bliźniacy ?? :) :) o jojo j grata na klawiiszach jaaa teeż :))
Haha, urządzenie w tle to mikser / nagrywarka / interfejs audio / wzmacniacz słuchawkowy. ;) Pozdrawiamy!
Scrum master to nieuk darmozjad w it