Scrum master i jego umiejętności

0

Siemanko!
Mam pytanko!
Czy wg. was Scrum Master powinien znać się na programowaniu i technologii w jakiej pracuje zespół, czy może być w tych tematach kompletnym laikiem?

0

To co my o tym sądzimy nie ma znaczenia. I tak scrum mastery robią co im się podoba.

0

Znać się na programowaniu - tak. Znać technologię w jakiej pracuje zespół - niekoniecznie. Ważne żeby uważał się za członka teamu i żeby chciał pomagać, a nie uważał się za kierownika który wie wszystko lepiej.

@Spine E tam. Ja do tej pory miałem trzech różnych scrum masterów, i kojarzę z 5 z innych teamów - wszyscy są spoko.

1

Czyli jeśli ScrumMaster nie zna się wcale na programowaniu, a w poprzedniej pracy był... barmanem, to niezbyt dobrze to wszystko wróży? ;)

2

Już sam fakt istnienia takiego odrębnego stanowiska jak Scrum Master dobrze nie wróży.

0

@somekind - chodzi Ci o to, że człowiek obejmujący stanowisko Scurm Mastera nie powinien obejmować go "na pełen etat", tylko w taki sposób, że sam coś kodzi i dodatkowo poświęca swój czas w ciągu dnia na kierowanie zespołem i pomoc?

2

Raczej odwrotnie - to ktoś, kto ma normalną, uczciwą pracę w projekcie, może dodatkowo pełnić rolę SM.

Ale - skoro SM jest potrzebny, to znaczy, że zespół nie potrafi się sam zorganizować, więc nie jest agile'owy. I albo tak jest naprawdę, albo kierownictwo twierdzi, że programiści są upośledzeni i potrzebują niańki. Zarówno jedno jak i drugie dobrze nie wróży.

0

Dzięki somekind za pomoc, potwierdziłeś tylko moje domysły :)

0

@somekind Albo np klient ma takie wymagania.
Dla mnie taki Scrum Master na pełen etat jest fajną sprawą przy większych projektach. U nas przy systemie pracuje 10 zespołów. Jakoś nie chciało by mi się (jako programiście) ogarniać komunikacji pomiędzy tyloma zespołami. W dodatku kontakt z klientem (kilkunastoma osobami od różnych spraw), pilnowanie Jiry, co chwilę jakieś spotkania techniczne i biznesowe, itd. A tak jest osoba na 2-3 zespoły która to wszystko załatwi.

1

@OverMorda ale osoba o której piszesz to jest manager a nie scrum master, niezależnie od tego jak tą pozycje u ciebie ktoś nazywa ;]

0

@somekind: Uważam, że nie masz racji.

  1. Co jeśli nad projektem pracuje kilka zespołów? Prawie zawsze żaden z deweloperów nie pcha sie do organizacji pracy między zespołami i woli zająć się swoim taskiem. I o ile organizacja pracy w jednym zespole jest w porządku, to synchronizacja pracy kilku zespolów często kuleje. Scrum master musi dbać o "scrum of scrums".
  2. Scrum master w moim obecnym projekcie zajmuje sie rozwijaniem funkcjonalności CI, CD i podobnych. Jak jest do postawienia maszyna wirtualna to on to robi. Jak ktoś chce nam wrzucić coś do sprintu to on dba o to, żeby nie było to możliwe.

Krótko mówiąc - jest sporo pracy nie związanej bezpośrednio z programowaniem, którą trzeba jednak wykonać. Tym może zajmować się scrum master w przerwie między stand-up'ami.

2

@pingwindyktator ale to wszystko nie należy do obowiązków scrum mastera o_O To jest raczej jakiś manager + devops. Jasne że można robić oba na raz i o tym zresztą mówiliśmy! Że programista/devops/tester/manager może PRZY OKAZJI być scrum masterem.

0

@Shalom: Uważacie, że nie ma miejsca na scrum mastera w dobrze zorganizowanym zespole. Ja uważam, że jak najbardziej jest miejsce na kogoś kto zajmuje się scrumem i jednocześnie pełni inne obowiązki. Czytaj uważnie.

0

@pingwindyktator kto i gdzie tak twierdzi? Zarówno ja jak i somekind piszemy zgodnie że miejsce na SM jest, ale nie jako osobna dedykowana pozycja tylko jako dodatek do zwykłej pracy.

0

"skoro SM jest potrzebny, to znaczy, że zespół nie potrafi się sam zorganizować"

0

Stanowisko SM moze miec wytlumaczenie jesli bierze udzial w kilku projektach i w kilku scrumach na raz...

W przeciwnym przypadku wiekszosc czasu bedzie siedzial na youtube i FB...

1
pingwindyktator napisał(a):

"skoro SM jest potrzebny, to znaczy, że zespół nie potrafi się sam zorganizować"

A co w tym dziwnego, że zespół nie potrafi się zorganizować? Dobrze zorganizowany zespół to jest co najmniej kilka miesięcy pracy, dużo wysiłku ze strony wszystkich członków zespołu, a i tak czasami z różnych przyczyn może nie wyjść. Programiści nie zawsze mają umiejętności menadżerskie, społeczne i komunikacyjne by samodzielnie zbudować dobry zespół.

0
OverMorda napisał(a):

Dla mnie taki Scrum Master na pełen etat jest fajną sprawą przy większych projektach. U nas przy systemie pracuje 10 zespołów. Jakoś nie chciało by mi się (jako programiście) ogarniać komunikacji pomiędzy tyloma zespołami. W dodatku kontakt z klientem (kilkunastoma osobami od różnych spraw),

Co to znaczy "ogarniać komunikację"? Nie można po prostu napisać na mailu, skypie, slacku do danej osoby/zespołu? Co jest trudnego w samodzielnym dopytaniu klienta o coś?

W nieskrzywionych organizacjach nie ma takich problemów. Problemy z komunikacją powstają wówczas, gdy w jej celu tworzy się specjalne, wyznaczone stanowiska, a reszcie ludzi zabrania się komunikować. Albo gdy tworzy się procesy i procedury polegające na komunikacji na siłę, zamiast po prostu pozwolić wymieniać informacje wtedy, kiedy tego potrzebują.

pilnowanie Jiry

Ale, że co dokładnie i jak się to niby przekłada na komfort pracy programisty?
Wykonuje za Ciebie klika kliknięć w tygodniu?
Czy może macie taska od każdej linijki kodu, i wszystkie trzeba uzupełniać co do minuty, żeby wykresiki dla góry się zgadzały? Jeśli tak, to znowu jest to sztucznie stworzony problem organizacji.

co chwilę jakieś spotkania techniczne i biznesowe, itd. A tak jest osoba na 2-3 zespoły która to wszystko załatwi.

Kolejny sztuczny problem. Jakby nie robić "co chwilę spotkań", to nie byłoby problemu, że ktoś musi je załatwiać.

pingwindyktator napisał(a):

@somekind: Uważam, że nie masz racji.

  1. Co jeśli nad projektem pracuje kilka zespołów? Prawie zawsze żaden z deweloperów nie pcha sie do organizacji pracy między zespołami i woli zająć się swoim taskiem. I o ile organizacja pracy w jednym zespole jest w porządku, to synchronizacja pracy kilku zespolów często kuleje. Scrum master musi dbać o "scrum of scrums".

Tylko dlaczego zespoły mają synchronizować pracę? Czemu nie podzielić zadań pracy tak, aby zespoły nie kolidowały ze sobą?
Kwestia jeszcze tego - jaki rodzaj pracy, i jak duże są zespoły.

  1. Scrum master w moim obecnym projekcie zajmuje sie rozwijaniem funkcjonalności CI, CD i podobnych.

Cholera, wychodzi na to, że jestem scrum masterem. ;)
A tak na serio, to ja rozumiem, że u Was devops pełni rolę SM, czyli mowa o przypadku, który opisałem wcześniej: "ktoś, kto ma normalną, uczciwą pracę w projekcie, może dodatkowo pełnić rolę SM"

Tym może zajmować się scrum master w przerwie między stand-up'ami.

Ta przerwa jest raczej dość długa, tak rzędu 7,75 roboczogodziny.
Dla mnie SM to funkcja dodatkowa, okazyjna i może być nawet przechodnia.

pingwindyktator napisał(a):

"skoro SM jest potrzebny, to znaczy, że zespół nie potrafi się sam zorganizować"

Może nie mam racji, ale tak zawsze słyszałem. W końcu w agile chodzi o samo organizujące się zespoły, a tu się okazuje, że nawet do dziesięciominutowego spotkania potrzebny jest wodzirej. :P

datdata napisał(a):

A co w tym dziwnego, że zespół nie potrafi się zorganizować?

Nic dziwnego. Zastanawiające jest jedynie to, że te zespoły, który nie potrafią się zorganizować występują jedynie w firmach, które o agilu mówią na lewo i prawo. W firmach, w których nikt się buzzwordami nie podnieca, problemów z organizacją jakoś nie ma.

Programiści nie zawsze mają umiejętności menadżerskie, społeczne i komunikacyjne by samodzielnie zbudować dobry zespół.

Ale to chodzi o wytwarzanie softu czy zakładanie boysbandu?

0

Uwielbiam dyskusje programistów :) Jako SM wypowiem się, że techniczna wiedza nie jest potrzebna ale przydaje się, żeby zrozumieć o czym mówimy na codzień. Cięzko byłoby odnaleźć się w świecie IT, jeśli nie lubi się technologii lub nie rozumie na czym polega development. To trochę sadomaso, a nie każdy lubi Grey'a :)
Techniczny SM? Dzielący pracę developera? A co z pokusą robienia code review "bo wiem o co chodzi" - powstaje wtedy ryzyko mieszania w projekcie.

Macie rację - przy dobrze zgranych, samoorganizujących się zespołach, SM nie jest potrzebny. Nawet więcej - dobry SM odejdzie sam z takiego zespołu, bo wie, że już nie ma w czym pomagać, ewentualnie raz na jakiś czas, jako agile coach poprowadzi ciekawszą Retro, zrobi mały audyt albo doglądnie procesu. Wydaje mi się, ze na tym polega właśnie klasa dobrego SM, że wie kiedy ze sceny zejść i odciąć pępowinę.
Może macie zespoły, które są zgodne i bezkonfliktowe. Z mojego doświdaczenia wynika jednak, że jak wchodziłam do zespołów jako SM, miały one różne dysfunkcje (więcej na ten tema w "Pięciu dysfunkcjach zespołu") i jest masa rzeczy do zrobienia. Największą satysfakcją dla SM jest pozostawienie zespołu w dobrej kondycji i świadomość, że jest się już niepotrzebnym. Szkoda tylko że mało kto ma tyle w sobie pokory żeby to przyznać :)
pozdrawiam was wszystkich!

1 użytkowników online, w tym zalogowanych: 0, gości: 1