Wpis z mikrobloga

Kij tam, niech stracę. Ogólnie jak ktoś zaczyna dyskusję (tutaj o #scrum i SM) to powinien posiadać elementarną wiedzę o temacie a nie głośno krzyczeć powtarzając przy okazji 'W sumie nie wiem jakie sa obowiązki SM' bo to jest idiotyczne podejście.
Ale macie, uprzedzając pytanie co dwa dni 'Czym zajmuje się SM' wkleję tu mój komentarz na przykładzie mojego projektu:

Zacznijmy od tego, że nie jestem SM (co niektórzy hejterzy mi tu przypisują tylko dlatego, że nie zgadzam się z ich ślepą nienawiścią do tej pozycji). Pracowałem jednak z nieudacznymi scrum masterami (którzy byli nimi tylko z nazwy) oraz naprawdę ogarniętymi, którzy robili dużą różnicę w projekcie. Mogę Ci więc opisać kilka obowiązków i działań które przyczyniły się do poprawy jakości naszej pracy, ogólny zarys można wygoglować szukając pierwszej lepszej oferty lub opisu stanowiska.

(z góry przepraszam za wklejanie angielskiej terminologii ale od lat pracuję w zagranicznych firmach i nawet nie mam pojęcia jak i czy tłumaczy się niektóre zwroty)

- Dobór narzędzi - zmienialiśmy przestarzałego bug trackera (na który narzekaliśmy na kilku retro ale o tym za chwilę) i SM nadzorował proces. Szukał innych rozwiązań, rozmawiał z firmami, ostatecznie poszliśmy w Jirę i on ogarniał potrzebne nam funkcjonalności co by potem przekazać wiedze mniej doświadczonym pracownikom na szkoleniach, tworzył dashboardy ogólnofirmowe, pomagał z tymi teamowymi itd. Teraz jest contact pointem między supportem Jiry a naszą firmą.

- Nadzór na sprintami aby działać wg scrumowej metodologi - wcześniej pracowaliśmy w czymś w rodzaju waterfalla który nawet nim nie był. Totalny chaos. SM wprowadził scrum, zaznajomił nas z nim i aktualnie pracuje się o niebo lepiej. Sprinty są uporządkowane, przejrzyste, ze ściśle określonymi goalami, sm pilnuje ile ticketów chcemy wziąć do sprinta (przy kooperacji z PO) tym samym nie kończymy z kupką nieruszonych spraw.

- Nawiązując do tego - sprawowanie 'pieczy' nad naszym velocity i burndown chartami dzięki czemu zespół nauczył się już ile może w sprincie zrobić i czego się wystrzegać podczas planningów.

- popularne 'impediment remover' - SM jest u nas osobą kontaktową jeśli masz problem ze sprzętem, procesem, softem, w organizacji. Nie wiesz do kogo zgłosić się bezpośrednio, rozmawiasz z SM i on to eskaluje lub pomaga. Często sam myśli o potencjalnych przeszkodach które napotkamy (np. zaczynając nowy feature) i zawczasu rozwiązuje problemy które jeszcze nie powstały.

- nadzorowanie spotkań - rolą SMa nie jest prowadzenie spotkać (co większość tu zarzuca) ale sprawianie, żeby były wartościowe. I tak, powie czasem na daily żebyście kończyli i przenieśli dyskusję do prywatnej rozmowy i to jest jak najbardziej ok bo w innym wypadku 6 osób siedzi i słucha kłótni dwóch devów przez 10 minut na tematy o których nie mają pojęcia / zupełnie ich nie interesują.

- retrospective i sprawianie, żeby były to wartościowe spotkania - wcześniej mieliśmy coś na wzór retro ale polegało to na narzekaniu na firmę, procesy. I tyle z tego było. Aktualnie masz pewność, że jeśli coś przeszkadza lub masz dobry pomysł to ktoś się tym zajmie. Efektem finalnym spotkań są ZAWSZE akcje które zazwyczaj są ruszane do następnego retro (czyli w góra 2 tygodnie widzisz jakiś rezultat).

- i te mityczne sprawowanie pieczy nad pracą wg metodologi scrumowej - nie wiem czemu tak wielu to boli ale pracujecie wg pewnych zasad i reguł i ktoś musi tego pilnować. Było tak zawsze i wszędzie - niezależnie czy pracowaliście w kanbanie, waterfallu czy nawet czymś bez nazwy, zawsze jest ktoś to musi tego pilnować. Tu robi to SM bo posiada odpowiednią wiedzę.

I wiele wiele innych

To tak 'pokrótce' jak to wygląda u mnie w zespole. Z tego co widzę większość hejtu i wyśmiewania tutaj wywodzi się z powielania zupełnie nieprawdziwych mitów lub wcześniejszej styczności z SMami którzy nimi być nie powinni i nie robili tego co do nich należy.

Także pora na mnie

#pracawit #pracbaza #programista15k
  • 42
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@ATAT-2: 1 godzinę roboty na miesiąc rozdystrybuowałem... ostatnio gadałem z firmą rekrutacyjną, gdzie scrum master jest na 5 zespołów, u nas był na 2, a teraz go wypieprzyli i project manager przejął prowadzenie daily.
  • Odpowiedz
project manager przejął prowadzenie daily.


@aczutuse: super. Jeśli Twoja firma wychodzi z założenia że rolą scrum mastera jest prowadzenie daily (bo nie jest) to gratuluję wiedzy w organizacji i sprawnego wprowadzdnja do niej "scruma"
  • Odpowiedz