Realna rola scrum mastera

Być może był już podobny temat a na pewno jest pełno śmieszków z SM jakoby pili tylko kawę i byli szkodnikami (pozdrawiam @KamilAdam :D). Czy aby te wszystkie śmieszki to tylko śmieszki, czy jednak coś jest na rzeczy? Natchniony własnymi doświadczeniami z ostatnich tygodni postanowiłem podzielić się pewnymi obserwacjami.

Z założenia SM ma pomagać dla zespołu pod kątem organizacyjnym, komunikacyjnym itp. oraz jak wiadomo strać na straży tego przybytku bólu i rozpaczy jakim jest sam scrum.

Jak to wygląda realnie przynajmniej u mnie?

• Ogarnięcie dostępów (approvale, konkretni ludzie): Not my scope
• Komunikacja z innym zespołem (agenda pytań (od zespołu) , ustalanie spotkań): Not in my scope
• Przedstawianie tasków zespołu na PI planningach: Not in my scope

Ogólnie większość softskillowych tasków, do których nie trzeba zaprzęgać technicznych osób to nadal nie jego scope.

Być może czegoś nie dostrzegam i nie do końca rozumiem roli SM stąd mój osąd jest z założenia błędny. Jedyne co zanotowałem to wprowadzanie chaosu do ogólnej pracy oraz zajmowanie sporej ilości czasu, mało przydatnymi spotkaniami dla samej idei. Z których oczywiście nic nie wynika. Coś na zasadzie 2+2 = 4 -> Nie mozna tego w prosty sposób rozwiązać. Musi być godzinny planning, refinment, estymacja w hipsterskich story pointach i ciąganie ludzi za język, żeby tylko wydali z siebie dźwięk bo tak musi być w scumie.

Stąd moje pytanie. Jakie są/powinny być obowiązki SM? Czy jest on niezbędny?

https://www.scrum.org/resources/what-is-a-scrum-master

ledi12 napisał(a):

Musi być godzinny planning, refinment, estymacja w hipsterskich story pointach i ciąganie ludzi za język, żeby tylko wydali z siebie dźwięk bo tak musi być w scumie.

Ale po co SM na refinemencie? Przecież to czysto techniczne spotkanie! :|

Stąd moje pytanie. Jakie są/powinny być obowiązki SM? Czy jest on niezbędny?

Nie wiem czy niezbędny, ale jeśli ktoś go zatrudnił i płaci, to niech robi to, co do niego należy. Czyli:

• ogarnianie dostępów;
• poganianie ludzi z innych teamów w kwestii jakiś zależności;
• częściowe dogadywanie zależności między zespołami (a raczej pilnowanie, żeby zadbał o to PO i TL)
• pilnowanie urlopów, świąt i innych kwestii mających wpływ na realizację planów.

Jeśli Twój tego nie robi, to nie jest nawet Scrum Master, to coś znacznie gorszego.

Moja narzeczona jest Scrum Masterem i głównie to co robiła np. dzisiaj to zorganizowanie rano Daily, przepytaniu programistów co robią no i potem zostawia laptop włączony, w sensie na tzw. czujce. Jak dostaje wiadomość to słychać w mieszkaniu na Teams, więc reaguje szybko.

Głównie to reaguje kiedy jest jakaś potrzeba, najgorsze ma dni kiedy jest zakończenie Sprintu, rozpoczęcie Sprintu planningi. Tak to głównie szczerze mówiąc nudzi się, przeglada sklepy, ogląda youtuby, nieraz obiad gotuje itp.
Pracy, jak mam porównać do mojej jako Deva to tyle co kot napłakał. Dla mnie jest to fenomen w branży to stanowisko i że to ktoś klepnal, zatwierdził.

nie wszedzie byla dedykowana osoba jako SM ale jesli juz bylo to zadanie polegalo po prostu na przepytanie po kolei ludzi na daily co robia i pare razy w miesiacu cos dogadac z product ownerem (jakies dodatkowe pytania). bylo to jakies 20min dziennie pracy srednio. placone za 8h stawki jak senior dev :)

kevin_sam_w_domu napisał(a):

Pracy, jak mam porównać do mojej jako Deva to tyle co kot napłakał.

No tak, w końcu. ;)

W dużym projekcie jest niezbędny, bez niego jest bałagan i chaos. Zaczynając od dopilnowania nieprzekazywania opisu skomplikowanych zadań w 1 zdaniu a później sobie dopytaj, a kończąc na sprzataniu bałaganu w ticketach. Dopilnowaniu przepisania do następnego sprintu itd. Praca bez niego nie jest komfortowa.

Odpowiadając wprost na pytanie - tak, moim zdaniem scrum master powinien ogarniać te wszystkie tematy co wymieniłeś. Pracowałem z oboma przypadkami. Był scrum master, który starał się pomagać ze wszystkim - był szanowany, czuł się częścią zespołu, praca szła naprawdę szybciej bo była wymierna pomoc. Po prostu to działało. Później pracowałem z innym scrum masterem właśnie z podejściem minimalistycznym - wszyscy byli wkurzeni bo zabierał czas i nie widzieli pozytywów z jego obecności, a wszelkie spotkania były organizowane bo tak napisano w scrum guidzie, a nie bo było to konieczne. Gdy po kilkunastu miesiącach gdy potrzebowaliśmy pilnie pomocy, a on kolejny raz odmówił bo w zasadzie przez cały okres pracy nawet nie poznał podstaw aplikacji to nastąpiło przelanie czary goryczy. Poszedł jasny sygnał, że scrum master nie jest nam potrzebny i został zwolniony. Od tego czasu pracujemy bez scrum mastera i dajemy sobie radę lepiej niż gdy jeszcze pracował bo proces jest lepiej dopasowany do projektu i potrzeb zespołu.
Dawniej scrum master był potrzebny aby nauczyć ludzi pewnego podejścia bo była to jeszcze nowość i minimalistyczne podejście mogło wystarczać. Obecnie ta rola powinna być zupełnie inna. Tak samo ewoluują obowiązki deva i QA

Mam taką teorię, że po prostu pewni mądrzy ludzie dostrzegają pewne problemy istniejące w naszej branży. Jako, że swego czasu byłem z drugiej strony barykady to widzę je praktycznie w każdej firmie dla której pracuję. Dużo by tutaj mówić, ale streścić to można tak, że ludzie w IT nie do końca wiedzą co robią + w dużym stopniu są niekomunikatywni. Niekomunikatywność to nie jest cecha IT a ogólnie chyba taka średnia z populacji, ale akurat w naszym zawodzie komunikacja jest bardzo istotna czego wielu programistów sobie nie uświadamia.

Trudno to trochę określić, ale taki banalny przykład rozjazdu między programistami a biznesem. Realizowaliśmy kiedyś projekt dla sieci sklepów wielkopowierzchniowych (sieć miała +100 sklepów). Średnio raz w tygodniu wpadał task na "rollback" błędnie wystawionego dokumentu, czego nie można było zrobić z interfejsu tylko trzeba było grzebać w bebechach. Za każdym razem, gdy taki task wpadał było wielkie narzekanie na debili z USA, którzy nie potrafią ogarnąć, że czegoś się nie powinno robić w systemie i ciągłe narzekanie, że nikt tych ludzi nie przeszkoli etc.
Dla kogoś kto zarządzał ludźmi to jest oczywista oczywistość, że nawet jak ludzi przeszkolisz to po miesiącu i tak ktoś zrobi coś źle, a tu jeszcze mówimy o +100 dużych sklepach wielkopowierzchniowych, gdzie pewnie w skali roku przewijają się tysiące pracowników.
Jako poważna firma powinniśmy zaproponować jakieś rozwiązanie, ale oczywiście kończyło się na kręceniu nosem i odkręcaniu problemu.

Taki scenariusz w tej czy innej formie obserwowałem w każdej firmie. Ludzie albo nie widzą problemu, albo zamiast go zgłosić to kiszą to w sobie. Jeśli ktoś ma doświadczenie w zarządzaniu ludźmi to potwierdzi, że wielokrotnie miał sytuację, gdzie jego podwładni od dawna wiedzieli o jakimś problemie, ale nikomu nie przyszło do głowy go zgłosić. Tu na forum też widzę takie posty typu, ktoś ma niewygodne krzesło w firmie więc... postanawia zmienić firmę na taką, która lepiej o niego zadba i nawet do głowy mu nie przyjdzie o tym pogadać z ludźmi, którzy to mogą zmienić - co najwyżej sieje ferment wśród osób z pokoju.

I tu w teorii wchodzi rola scrum mastera. W teorii to jest taki człowiek, który to wszystko z ludzi powinien wyciągnąć, zachęcać do rozmowy, zgłaszania problemów. Taka osoba, która powinna zawsze być w kuchni jak idziesz na kawę i delikatnie przekazywać do góry problemy z dołu - czy to stricte projektowe, czy takie czysto organizacyjne.

Problemy są tylko dwa:

• zestaw takich soft skilii, które sprawiają że osoba potrafi rozmawiać, wyciągać wnioski, łagodzić problemy itd to jest rzadkość - do tego aby SM był skuteczny moim zdaniem musi przynajmniej orientować się w aspektach technicznych aby móc zrozumieć pewne problemy
• oczywiście jak to w korpo - szczytne ideały sprowadza się do parteru pomysłami typu SM na godziny czy zdalnie, raportowanie itd.

Jak SM nie dorósł do swojej roli to niestety zamiast fajnego rozwiązania robi się kolejna zbędna warstwa abstrakcji ;(

Dla mnie SM, który jest nietechniczny i nie robi nic z tych rzeczy które wymieniłeś i ma tylko jeden zespół pod sobą to typowy "bullshit job", który firma utrzymuje chyba na pokaz, bo pożytku z tego żadnego nie ma. O takim prawdziwym SMie możemy mówić kiedy ma pod sobą ileś zespołów przypisanych, gdzie organizuje dla każdego z nich scrumowe spotkania, zarządza jirą, zakłada epiki w porozumieniu z BA i sam ma dużo swoich spotkań z ludźmi od biznesu - wtedy rzeczywiście takie stanowisko ma sens. Inaczej najlepiej wybrać jakiegoś dewelopera/osobę techniczną z zespołu która będzie się zajmować organizacją spotkań, planowaniem, retro etc, bo to robota na 2-3 godziny w tygodniu, a w resztę czasu można robić coś sensownego.

Jeden scrum master/agile coach który wprowadził jakąś zmianę na moich oczach był osobą która była przypisywana do problematycznych projektów. Generalnie miał błogosławieństwo z góry żeby wytykać ludziom (w tym wysokim managerom) wszystkie bezsensowne rzeczy które robią - za dużo spotkań, za mało decyzji, burdel w backlogu, niejasne wymagania, paralysis analysis, deployowanie raz na miesiąc. Swoje obserwacje wysyłał z CC do sponsorów projektu. Tak naprawdę robił 50% roboty project managera i 50% inkwizytora.

IMO scrum master, to po prostu kolejna korpo-rola, jak wiele innych zbędnych ról w korporacjach. Oczywiście, część pracy wykonywanej pracy przez scrum mastera może i daje jakiś tam pożytek, ale nie wymaga to pełnego etatu. No bo co takiego ma robić ten scrum master pomiędzy standupami (15 minut dziennie) i retrospektywami (od 1h do 2h w porywach co 2 tygodnie)? Oczywiście trzeba się przygotować do tych spotkań, ale w gruncie rzeczy, scrum master moderuje te spotkania, a nie aktywnie w nich uczestniczy, więc w zasadzie nie musi się do tego specjalnie przygotowywać.

Wg mnie, nietechniczni scrum masterzy na pełen etat, to są sprytne cwaniaki, które zahaczyły się w IT i koszą hajs za kawał nikomu niepotrzebnej roboty, a przez większość czasu nie robią nic.
Pracowałem w firmach ze scrum masterami oraz bez scrum masterów i widzę, że jeśli ludzie są rozgarnięci i odpowiedzialni, to ten cały korporacjonizm nie jest nikomu do niczego potrzebny.

Żeby nie było, że jestem jednostronny, to spotkałem się też z bardzo ogarniętymi scrum masterami, którzy rozwiązywali różne problemy zespołów, a także problemy między-zespołowe, organizacyjne, a nawet techniczne, za które nikt się nie chciał zabrać. Tego typu osoby, to już są w zasadzie takimi managerami z wysokimi technicznymi i miękkimi umiejętnościami na innym poziomie świadomości i wykonują obowiązki wykraczające ponad swoje bazowe kompetencje, a scrum masterami, to są jedynie na papierze.

Całkowicie zgadzam się z tym, o czym pośrednio jest tu mowa - SM jest rolą mniej ważną od developera, bo jest czystym kosztem. To programiści tworzą wartość. Bez SM'ów firma jest jakoś w stanie funkcjonować. Bez developerów nie ma takiej opcji. W zasadzie managerowie i inne stanowiska też są kosztem. Powinni naprawdę być bardzo kumaci i ogarnięci w tym co robią, żeby udowodnić, że tworzą developerom dobre środowisko do pracy. Zbyt mało ludzi to jednak rozumie.

Dobry SM to przede wszystkim osoba, która nie wpiernicza się w działanie zespołu, daje mu decydować o sobie, a jak jest jakiś problem, to upewnia się, że w zespole zachodzi proces empiryczny. To oznacza, że SM:

1. Upewnia się, że zespół widzi problem, a jeżeli tak nie jest, to mu go pokazuje, jak wszyscy nie widzą albo nie chcą widzieć problemu.
2. Upewnia, się, że zespół stara się samodzielnie cokolwiek zrobić w kierunku rozwiązania. Jeżeli nie może i nie ma pojęcia, co zrobić, to eskaluje problem i stara się go rozwiązać, bo jego rola jest odpowiedzialna za efektywność zespołu. Jak zespół nie jest efektywny, to jest to w interesie Scrum Mastera, żeby pomóc mu takim być. Przy czym SM nie daje gotowca, czyli tzw. ryby, a najlepiej wędkę, albo gdzieś z boku kładzie książkę o wędkarstwie, bo zmiana wychodząca od samego zespołu najlepiej uczy i jest najtrwalsza.
3. Poprzedni punkt wyraźnie też wskazuje kolejny - SM nie narzuca zespołowi żadnych zmian, bo to głupota. Zespół ma decydować o nich wspólnie. On powinien jedynie mieć oczy dookoła głowy, widzieć rzeczy z różnych perspektyw i doradzać.
4. Nie stara się ślepo i na siłę ewangelizować Scrumem, jednocześnie mając głębokie zrozumienie tego, po co wszystkie zawarte elementy tam są, a nie implementować wszystko na siłę.
5. Dopasowuje swoje metody do poziomu dojrzałości zespołu.
6. Jak zespół chce coś spierdzielić, to daje mu to zrobić, bo to najlepiej uczy. Ważne jest jednak to, żeby chociaż ostrzegał. Wyjątkiem jest sytuacja, w której takie popełnienie błędu jest na tyle kosztowne, że nie można sobie na to pozwolić.
7. To już moja osobista opinia: dobry SM był wcześniej developerem, bo wtedy najlepiej rozumie problemy zespołu, skoro sam się kiedyś z nimi boksował.

Na nasze nieszczęście rynek jest zalany niekompetentnymi SMami, którzy się do tego nie nadają i tego nie rozumieją. To właśnie oni sprawiają, że developerom tak bardzo te ramy obrzydły. W sumie to jest główny powód, dla którego nie zamierzam zrezygnować z bycia programistą (a kilka lat temu się do tego przymierzałem robiąc PSM II, PSPO II i inne papierki).

Według mnie Scrum Master to nie jest praca etatowa. Jest to praca zleceniowa/kontraktowa. Przychodzi taki Scrum Master : pomaga organizować zespół, pokazuje narzędzia, klaruje jakąś wizję, zwraca uwagi na problemy zespołu i jak sobie z nimi radzić. No i po takich 6 miesiącach pracy zespół jeśli skorzysta z tych wszystkich rad i praktyk powinien być samoulepszającym się bytem i znacznie poprawić wszystkie aspekty - nie potrzebuje już Scrum Mastera. Aktualnie pracuje w projekcie, w którym tak to wygląda. Scrum Master był, zrobił swoje i poszedł. No ale do tego jest potrzeba proaktywnego podejścia wszystkich członków zespołu i przekonania się do tego, że takie różne pierdoły wpływają na lepszą organizację pracy i dowożenie tematów.

Czy potrzebujemy teraz w zespole SM? Nie.
Czy dzięki SM możemy go teraz nie potrzebować? Tak.

W projekcie są do ogarnięcia różne rzeczy administracyjne, komunikacja, przypilnowanie czy taski mają właściwe statusy, czy ludzie robią to co jest pilne, a nie to co im w ręce wpadło i czy nie biegamy z pustą taczką, bo nie ma kiedy jej załadować. Tym powinien zajmować się ktoś w roli SM. Mam w tej chwili SM, która ogarnia te sprawy i jest zarąbana robotą (serio). W mniej sztywnych organizacjach i ogarniętych zespołach może to spokojnie ogarniać np. jeden z programistów.
Niestety korpo uwielbia zatrudniać ludzi na stanowisku SM, nie zwracając uwagi na to kogo się zatrudnia. Czyli praktycznie ląduje w projekcie osoba, która przeczytała jakiś komiks o adżajlu, albo odbyła 2 dniowe szkolenie, ma w głowie jakieś pierdoły, których nie rozumie, bo nie ma pojęcia o np. software development life cycle, nie wie o co chodzi z tą całą definition of done, nigdy nie robiła dokładnie niczego związanego z tworzeniem oprogramowania. Ot, pracowała sobie w McDonalds, ale poszła na szkolenie, dostała certyfikat, znalazła pracę w korpo, nie daj boże jeszcze jej wpisali w nazwie stanowiska "manager". W dodatku ten kurs był organizowany przez firmę specjalizującą się we wdrażaniu jakieś tam formalnej metodyki adżajlowej i im nie zależy na tym, żeby klient tworzył oprogramowanie efektywnie, tylko na tym, żeby płacił i wysyłał więcej ludzi na te szkolenia i certyfikaty.
W efekcie tego, taki SM:

• Organizuje spotkania, które są kompletnie nie potrzebne, a nawet jeżeli są potrzebne, to ich forma przekreśla możliwość jakiegokolwiek postępu.
• W najmniej odpowiednim momencie (jakiś deadline, albo wtopa na produkcji) łazi i smęci, że "trzeba przegadać czym jest 1 story point, bo nasze estymaty są niedokładne" i nie przetłumaczysz, że to nie jest dobry moment, a estymaty z definicji są niedokładne, bo w komiksie nie było nic na ten temat, a kurs prowadził taki gość, co powiedział, że ma doświadczenie i wyglądał na inteligentnego i waterfall nie działa, a agile działa
• Jak już zorganizuje to spotkanie na jakiś temat, to oburza się, że nikt nie chce nic powiedzieć, a dzieje się tak, bo, albo spotkanie jest kompletnie bezcelowe, albo nie ma co gadać, bo wszyscy z wyjątkiem SM mają pełną jasność w temacie, albo SM sam nie rozumie po co jest to spotkanie i tym bardziej nie jest w stanie przekazać tej wiedzy innym.
• Jak pojawia się jakieś realne zadanie, typu trzeba zorganizować spotkanie, to święte oburzenie, bo przecież tej osobie płaca za bycie SM, czyli "wspieranie i kołczowanie zespołu, żeby pracował zgodnie z agilem", a nie robienie "za zespół jakiejś pracy".

I to co napisałem wyżej, to nie jest jakieś teoretyzowanie, tylko moje doświadczenia pracy z pewnymi osobami. Żeby uniknąć niedopowiedzeń - lubię podejście agile, uważam, że tworzenie oprogramowania, to popełnianie błędów, uczenie się na nich, udoskonalanie procesu i produktu, tak żeby nie wpadać co w chwila w te same problemy. Pracowałem też w waterfallu i w większości przypadków to było złe, być może przez ludzi, którzy zarządzali takimi projektami na takim samym poziomie jak dzisiaj zarządzają projektami "zwinnymi".

Piszę o podobnej tematyce pracę magisterską
Część scrum masterów ma bardzo przewidywalną pracę pomiędzy codziennymi zajęciami
prasowanie mężowi koszul 1h
telefon do jednego programisty czy nie ma jakiś problemów 5min
gotowanie obiadu 1h
telefon do drugiego programisty czy nie ma jakiś problemów 5min
sprzątanie 1h
telefon do trzeciego programisty czy nie ma jakiś problemów 5min

zespoły scrumowe zazwyczaj liczą do 10 osób więc można przestrzegać BHP i robić 5min pracy pomiędzy 1h przerwą.
Jeszcze żaden programista nie powiedział że ma jakiś problem

Z mojego doświadczenia jak SM pilnuje tasków, pogania inne zespoły, odpytuje na daily, czy robi za sekretarkę to właśnie słaby SM i objaw słabego zespołu i devów. Dobry SM to taki który to wszystko widząc pomoże tak się developerom, PO i innym ogarnąć w kwestii procesu, reguł, czy praktyk technicznych tak, żeby taki ogarniacz chlewu nie był potrzebny, bo w końcu pracują w nim inteligentni dorośli ludzie a nie banda dzieci. Dobry SM będzie też w stanie ocenić i powiedzieć że w danym kontekście scrum nie pomaga a przeszkadza i pomoże to zmienić nawet kosztem własnego stanowiska - na koniec dnia każdemu rozgarniętemu SMowi z którym się spotkałem zależało przede wszystkim na skuteczności zespołu.

NightDev napisał(a):

Z mojego doświadczenia jak SM pilnuje tasków, pogania inne zespoły, odpytuje na daily, czy robi za sekretarkę to właśnie słaby SM i objaw słabego zespołu i devów.

Możliwe, tylko ktoś te zadania musi zrobić. Jak ja moge robić za sekretarkę, to SM też może.

Dobry SM to taki który to wszystko widząc pomoże tak się developerom, PO i innym ogarnąć w kwestii procesu, reguł, czy praktyk technicznych tak, żeby taki ogarniacz chlewu nie był potrzebny, bo w końcu pracują w nim inteligentni dorośli ludzie a nie banda dzieci.

Oczywiście, tylko co w przypadkach kiedy ci PO, programiści już są ogarnięci, a SM dalej biega z kredkami i kolorowymi karteczkami rozwiązując nieistniejące problemy? I w jaki sposób SM bez doświadczenia technicznego pomoże mi wybrać te najlepsze praktyki techniczne?

Dobry SM będzie też w stanie ocenić i powiedzieć że w danym kontekście scrum nie pomaga a przeszkadza i pomoże to zmienić nawet kosztem własnego stanowiska - na koniec dnia każdemu rozgarniętemu SMowi z którym się spotkałem zależało przede wszystkim na skuteczności zespołu.

Ilu takich spotkałeś w życiu? 1/5? Bo Z mojego doświadczenia te pozostałe 80% będzie krzyczeć "ludzie i interakcje ponad procesy i narzędzia" jednocześnie tocząc święte wojny o jakieś nieistotne pierdoły typu kolor karteczki, albo pilnować, żeby ludzie nie brali żadnych zadań, bo "burndown chart będzie brzydki".

@trybuszon: prawie się zgadzam, prawie bo "work not done" jest bardzo ważna, nie tylko praca done (agile manifesto #10 principle) oraz praca nie na temat jest jednym z większych waste (lean), więc stwierdzanie że "developer" jest ważniejszy do kogokolwiek (tutaj SM, ale też PM, sales czy accounting) jest mocno na wyrost, każdy ma jakąś rolę do odegrania i jeśli któraś szwankuje to cały zespół szwankuje; taka dyskusja czy w samochodzie ważniejszy silnik czy koła

Tak poza tym to ten filmik nadaje się na komentarz ogólny do tego wątku:

@Kaizen: Według mnie, żeby dostarczyć produkt klientowi (nie ważne, czy cały system, czy jakąś drobną funkcję trzeba:

• zapytać klienta czego chce i zrozumieć (Product Manager, Product Owner)
• zaprojektować jak to co klient chce ma zostać zrealizowane od strony UX i technicznej (UX designer, architekt)
• określić pilność zadania (PM/PO)
• zaimplementować (software developer)
• przetestować (software developer (in tests), PO, PM)

Oczywiście jest to wersja minimum, ale jeżeli mówimy o celu zdefiniowanym jako "dostarczenie działającego i zgodnego z oczekiwaniami klienta produktu" to nic więcej nie trzeba. Mogą się jeszcze pojawić zadania dodatkowe takie jak "na kiedy można to zrobić", "ile to będzie kosztowało"

Nie jeżeli mówimy o wymienionych wyżej rolach, to twoja analogia "silnik, czy koła" jest słuszna. Tylko jeżeli zgodzisz się, że te etapy opisane wyżej to minimum tego co trzeba zrobić, to wszystko ponadto, żeby było uzasadnione, musi usprawniać którykolwiek z tych punktów, jeżeli tego nie robi, to jest zwyczajną stratą kasy, czasu, wysiłku. SM w żadnym z tych punktów nie uczestniczy bezpośrednio, czyli w przypadku kiedy zespół radzi sobie z organizacją własnej pracy jest zbędny, a jeżeli nie potrafi usiąść w kącie i zająć się czymś pożytecznym, to będzie przeszkadzać w pracy.

@piotrpo: opisujesz waterfall nie agile

• najlepszą architekturę zgodnie z agile robi zespół
• zespół ma znać potrzeby biznesowe i rozmawiać z "klientem", nie tylko product ownerem
• pilność zadania to nie to samo co priorytet, PO określa priorytet, pilność to bardziej data, a ta w scrumie sprowadza się do tego który to sprint (ale np. Kanban to obsłuży, ale piszesz o PO, a Kanban nie ma takiej roli, taką ma Scrum)
• na kiedy będzie zrobione to wiadomo, po to są estymacje, które zmieniały się na przestrzeni scrum guide, ale są zawsze, więc jak nie wiesz kiedy będzie coś zrobione, to znaczy że backlog nie jest ready do sprintu, a jak wiesz -> no to wiesz czy to będzie w tym sprincie czy następnym
• ile będzie kosztowało też wiadomo = sprint to timebox czasowy, koszty zespołu developerskiego są czasowe, chyba że mówimy o tym że nie wiadomo z jaką złożonością obliczeniową zakończymy task i to zmienia czy w GCP przepalać będziemy 1k miesięcznie czy 20k miesięcznie.

Proces który opisujesz ma bardzo długi value stream (lean), nie przewiduje współpracy biznesu z developerami (agile manifesto #4 principle), oraz wprowadza rolę pozazespołowego UX designera i architekta (wbrew agile manifesto #11 principle). Tak da się robić oprogramowanie ale zamiast "zbędnej roli SM" masz w bezpośrednim sądziedztwie zespołu inne role, które tak samo zużywają zasoby firmy i bez tych ról oprogramowanie nie powstanie.

Uczciwie oceniając - to bardziej waterfall niż agile. Czy to źle? Niekoniecznie tj. masę oprogramowania tak zrobiono, wciąż robi się oprogramowanie w ten sposób, ten soft działa, ale ma to swoje określone i udowodnione wady - częste wyprodukowanie złej funkcjonalności (taką jaką klient chciał, ale nie taką jaką potrzebował), zdemotywowany zespół (architekt przerzuca wymagania przez płot, a ja wiem że za dwa tygodnie będziemy to przepisywać i lepiej być na to gotowym), długi value stream (wycena, budżet, zatwierdzenie -> 6 miesięcy, a potem zlecenie żeby było na za dwa dni) etc.

I teraz albo robimy agile, albo przestańmy się wygłupiać że jesteśmy zwinni (jeśli nie jesteśmy i nie chcemy być), tylko róbmy waterfalla porządnie - też się da. Wszystko lepsze niż tryb pożaru i burdelu, który jest defaultem.

Stwierdzenie "w przypadku kiedy zespół radzi sobie z organizacją własnej pracy jest zbędny" jest osobnym zagadnieniem. Zawsze da się coś poprawić. Jedyną osobą, która może to efektywnie zrobić jest osoba, która wykonuje dane zadanie. Niemniej osoba wykonująca zadanie nie ma możliwości stanąć z boku i przyjrzeć się jak to robi, albo co gorsza - nie ma na to czasu. Scrum dba o to by była przestrzeń na rozwój i refleksję, Scrum Master ma dbać o to by ta przestrzeń tam była oraz ma identyfikować co w ogóle jest do poprawy, bo jest w unikalnej pozycji w której pracę obserwuje z boku, więc łatwiej wychwytywać problemy, albo pomagać zespołowi identyfikować problemy. Rozwiązanie problemu (lub jego zignorowanie) to kwestia zespołu developerskiego.

Agile tylko z nazwy i scrum master prasujący koszule w pracy, to na pewno problem firm i programistów. Byłbym jednak ostrożny ze stwierdzaniem, że źródło problemu to scrum masterzy jako tacy. Ale tak, w waterfall scrum master jest zbędny.

@Miang: (w komentarzach):

Trójkąt projektu to czas, koszt, jakość - wybierz jedno. Agile pozwala dostać jakość, czyli działające oprogramowanie robiące to czego się od niego oczekuje. Na pytania "ile to będzie kosztować" i "kiedy to będzie" nie jest w stanie odpowiedzieć z definicji, bo poza kilkutygodniową perspektywą agile nie działa. Możesz podzielić sobie duża porcję pracy na elementy, a później nanosić ich wykonanie na wykres skończonaFunkcjonalność(czas) i wtedy masz sensowne szacunki "kiedy". Im więcej zrobione i im mniej do zrobienia zostało, tym szacunki bardziej wiarygodne, ale to działa w projektach o elastycznym czasie dostarczenia, albo elastycznej funkcjonalności. Czyli zgodnie z założeniem projektów zwinnych - robimy to co właśnie teraz jest potrzebne, przez ileś tam, za ileś tam i klient decyduje, czy przy takiej historii dostarczonych funkcji i przepalonej kasy chce iść dalej, czy mu się to nie opłaca.

Jeżeli masz projekt fixed price, to robisz to co masz w umowie, na takim poziomie jakości, żeby zmieścić się w czasie i budżecie. Skoro nie ma elastycznego zakresu projektu, elastycznego czasu i elastycznego budżetu, to manipuluje się jakością na poziomie DoD - wywalamy testy, refaktoryzację w trakcie pracy itp. Czyli wszystko jak w typowym Software House. Polak, hindus dwa bratanki.

Kaizen napisał(a):

@piotrpo: opisujesz waterfall nie agile

• najlepszą architekturę zgodnie z agile robi zespół

Nie, opisuję proces tworzenia oprogramowania. Czynności w których nie bierze udziału SM. Robi je człowiek lub ludzie w roli architekta. Nie musi być (i nie powinien) ktoś na zewnątrz zespołu. Wiedza na temat sensowności (i bezsensowności) wybranego rozwiązania pojawia się stopniowo. Powinien w to być zaangażowany cały zespół, ale w praktyce senior będzie miał tutaj więcej do powiedzenia, niż gość, który zaczął dopiero pracę.

• zespół ma znać potrzeby biznesowe i rozmawiać z "klientem", nie tylko product ownerem

Jasne, tyle teorii. W jaki sposób zespół ma znać potrzeby klienta kiedy pracuje nad np. usługą SaaS przewidywaną do posiadania np. miliona użytkowników? Pojawia się wtedy dodatkowa wyspecjalizowana osoba w postaci PO. Jeżeli projekt ma ogarnąć dużą i hermetyczną domenę, to "zespół rozumiejący biznes" jest mitem. Interesuję się tym co ma robić mój produkt, mam sporą wiedzę domenową z tej dziedziny jak na programistę. Nie ma natomiast szans, żebym wiedział więcej niż 5% tego co wie gość pracujący w tej domenie od 20 lat. Nie ważne, czy to jest bankowość, ubezpieczenia, czy lotnictwo. Naprawdę dużą wiedzę o domenie i potrzebach użytkownika miałem w 2-3 projektach w życiu, 2 były hobbystyczne (robiłem coś dla siebie i przy okazji publikowałem) i raz był to serwis do ustawiania spotkań - czyli narzędzie do czegoś z czym mam do czynienia na codzień. Co ciekawe, w tych projektach nie było SM.

• pilność zadania to nie to samo co priorytet, PO określa priorytet, pilność to bardziej data, a ta w scrumie sprowadza się do tego który to sprint (ale np. Kanban to obsłuży, ale piszesz o PO, a Kanban nie ma takiej roli, taką ma Scrum)

Nie ważne jak to nazwiesz, musi być ktoś (osoba/kawałek osoby/zespół), który to ogarnie.

• na kiedy będzie zrobione to wiadomo, po to są estymacje, które zmieniały się na przestrzeni scrum guide, ale są zawsze, więc jak nie wiesz kiedy będzie coś zrobione, to znaczy że backlog nie jest ready do sprintu, a jak wiesz -> no to wiesz czy to będzie w tym sprincie czy następnym

Dobre. Przypomnijmy że SP nie jest jednostką czasu (podobno), tylko zawiera w sobie element niepewności. Efekt jest taki, że możesz sobie planować, że coś będzie, a na koniec okaże się, że jednak nie wyszło. Bo ktoś złamał rękę, bo metoda, która wydawała się fajna okazała się nie działająca w praktyce. No i cały czas piszesz o sprincie. Powiedz ile będzie trwał średniej wielkości projekt przewidziany początkowo na 3 lata z budżetem ~10 000 000 USD.

• ile będzie kosztowało też wiadomo = sprint to timebox czasowy, koszty zespołu developerskiego są czasowe, chyba że mówimy o tym że nie wiadomo z jaką złożonością obliczeniową zakończymy task i to zmienia czy w GCP przepalać będziemy 1k miesięcznie czy 20k miesięcznie.

Ok, radzę sobie z arytmetyką. Tylko to jest "trochę" bardziej złożone. W perspektywie 2 tygodni oczywiście, że możesz z dokładnością ~10% przewidzieć co zostanie dostarczone i ile to będzie kosztowało. Tylko najkrótszy projekt w którym brałem udział trwał kilka miesięcy.

Proces który opisujesz ma bardzo długi value stream (lean), nie przewiduje współpracy biznesu z developerami (agile manifesto #4 principle), oraz wprowadza rolę pozazespołowego UX designera i architekta (wbrew agile manifesto #11 principle). Tak da się robić oprogramowanie ale zamiast "zbędnej roli SM" masz w bezpośrednim sądziedztwie zespołu inne role, które tak samo zużywają zasoby firmy i bez tych ról oprogramowanie nie powstanie.

Znowu - to czy UX/architekt będzie w zespole, czy poza nim nie ma znaczenia. Kolejna partia roboty, którą trzeba zrobić (kto i gdzie to wtórny problem), której nie wykonuje SM.

Uczciwie oceniając - to bardziej waterfall niż agile. Czy to źle? Niekoniecznie tj. masę oprogramowania tak zrobiono, wciąż robi się oprogramowanie w ten sposób, ten soft działa, ale ma to swoje określone i udowodnione wady - częste wyprodukowanie złej funkcjonalności (taką jaką klient chciał, ale nie taką jaką potrzebował), zdemotywowany zespół (architekt przerzuca wymagania przez płot, a ja wiem że za dwa tygodnie będziemy to przepisywać i lepiej być na to gotowym), długi value stream (wycena, budżet, zatwierdzenie -> 6 miesięcy, a potem zlecenie żeby było na za dwa dni) etc.

Agile i waterfall to to samo, istotnie różnią się jedynie liczbą iteracji i ich częstotliwością. W takim Kanbanie mamy iterację na poziomie pojedynczej historyjki, w Scrum na poziomie 2 tygodni a w waterfall będzie to np. 5 lat na stworzenie i wdrożenie sytemu informatycznego dla ZUS.

I teraz albo robimy agile, albo przestańmy się wygłupiać że jesteśmy zwinni (jeśli nie jesteśmy i nie chcemy być), tylko róbmy waterfalla porządnie - też się da. Wszystko lepsze niż tryb pożaru i burdelu, który jest defaultem.

Nieprawda. Agile powinien podlegać zmianom. Twoje "róbmy agile porządnie" oznacza "róbmy jak w komiksie dla SM". W efekcie czego celem projektu staje się "zrobienie adżajla" zamiast "zrobienie produktu". Ale pierniczenia o szacunku i dostarczaniu rzeczywistej wartości klientowi jest oczywiście niezwykle dużo.

Stwierdzenie "w przypadku kiedy zespół radzi sobie z organizacją własnej pracy jest zbędny" jest osobnym zagadnieniem. Zawsze da się coś poprawić.

Tylko jeżeli koszt zmiany jest duży a zysk z tej zmiany mały to nie ma sensu jej wprowadzać, bo netto wyjdzie na minus. Im lepiej zespół sobie radzi, tym mniejszy zysk z udoskonaleń (bo jest mniej do udoskonalania). To nie jest "osobne zagadnienie". To temat tego wątku. SM, jako człowiek, który robi jedynie robotę SM to wyrzucanie pieniędzy w błoto. Nie ma wiedzy biznesowej, nie ma wiedzy technicznej. Pół biedy, jeżeli nic nie robi, ale zwykle lubi poprzeszkadzać w pracy.

Jedyną osobą, która może to efektywnie zrobić jest osoba, która wykonuje dane zadanie. Niemniej osoba wykonująca zadanie nie ma możliwości stanąć z boku i przyjrzeć się jak to robi, albo co gorsza - nie ma na to czasu. Scrum dba o to by była przestrzeń na rozwój i refleksję, Scrum Master ma dbać o to by ta przestrzeń tam była oraz ma identyfikować co w ogóle jest do poprawy, bo jest w unikalnej pozycji w której pracę obserwuje z boku, więc łatwiej wychwytywać problemy, albo pomagać zespołowi identyfikować problemy. Rozwiązanie problemu (lub jego zignorowanie) to kwestia zespołu developerskiego.

Tak, wiem "ja tu się jedynie przyglądam i podpowiadam. Moją rolą jest zachęcenie was do korzystania ze Scrum" Słyszałem zbyt wiele razy w życiu.

Agile tylko z nazwy i scrum master prasujący koszule w pracy, to na pewno problem firm i programistów. Byłbym jednak ostrożny ze stwierdzaniem, że źródło problemu to scrum masterzy jako tacy.

Nie wszyscy. Miałem dobre doświadczenia z SM, ale w większości przypadków naprawdę to prasowanie koszul w trakcie pracy byłoby mniejszym złem.

@piotrpo:

Agile i waterfall to to samo

Chyba tyle w temacie, bo jak to dla Ciebie jest założenie (nie wyprowadziłeś tego, podałeś to wprost), to rozmawiać o różnicach sensu nie ma.

Zgódźmy się więc, że się nie zgadzamy, do czego szczególnie zachęciły mnie wpisy na Twoim mikroblogu.

ledi12 napisał(a):

Z założenia SM ma pomagać dla zespołu pod kątem organizacyjnym, komunikacyjnym itp. oraz jak wiadomo strać na straży tego przybytku bólu i rozpaczy jakim jest sam scrum.

Yyyy, nie. Być może masz na myśli managera?

Z zalożenia Scrum Master jedyne co ma robić, to pilnować żeby scrum był przestrzegany.

To w jaką stronę ewoluowała ta pozycja i etykietka to już inna sprawa. Moim zdaniem w zespole jest potrzebna rola "ogarniacza", więc tą rolę z reguły dostaje SM albo PO; a jako że na "ogarniacza" nie ma żadnej modnej nazwy, to zostaje nazywany nadal SM lub PO.

Tutaj przykładowe rozumienie obowiązków SM przez jedną z sztywnych metodyk zwinnych. https://www.scaledagileframework.com/scrum-master/ W streszczeniu 90% to bulszity zaczynające się od:

• supports
• exhibits
• promotes
• facilitates
• enables

Jedyna rzeczywista robota w tym, to "Coordinates with other teams". Pomijam trening, bo ile można trenować dorosłych ludzi.

Co ciekawe nawet twórcy tej metodyki uważają, że 1 SM per zespół to przesada (ostatni akapit). Czyli posługując się słownictwem z poprzedniego, słusznie minionego systemu, czystej formy SM, według tej metodyki, to taki oficer polityczny - mało wie, mało rozumie, mało może, ale kocha partię.

IMHO rola scrum-mastera jest bezużyteczna, bo nie jest to osoba na stanowisku decyzyjnym(kierowniczym), więc może ona w sumie tylko poprosić o coś PMa, czyli taki głuchy telefon.

PS. z tego co widziałem, to jeśli zespół ma kompetencje i nie jest dyrygowany "z góry", to scrumowe pomysły są systematycznie usuwane, aż w końcu nie ma ani scruma ani waterfalla, po prostu robi się swoje i rozmawia kiedy trzeba i tyle. W przeciwnym wypadku scrum dąży do mikro-managementu. Scrum jest niestabilny i idealistyczny.

PSS. sorry za flame w PS.

Żaden flame, to co napisałeś, czyli wyrzucenie wszelkich zbędnych elementów procesu to oczywista optymalizacja. (Korpo-) Scrum w swojej zwinności zakłada, ze każdy zespół, w każdym projekcie i na każdym jego etapie będzie działał identycznie i będzie potrzebował tych samych narzędzi organizacyjnych.
Jeżeli zespół zaczyna i kompletnie nie ogarnia administracyjnej strony projektu, czyli nie wie co ma zrobić, nie wie po co, nie potrafi się komunikować, nie wie kiedy praca jest skończona (wystarczy napisać kod, czy musi się jednak kompilować, kompilować i działać, albo ma się kompilować, działać, być ładny, pokryty testami) to wprowadzenie Scruma/Kanbana z podręcznika i troche musztry ma sens bo to co proponują te metodyki nie jest z gruntu rzeczy złe. Ostatecznie takie rzeczy jak:

• sprawdzenie, czy to czego chce biznes da się przeczytać (backlog refinement)
• sprawdzenie, czy nikt nie utknął z zadaniem, które go przerasta i już nawet się za nie nie bierze, bo woli przeglądać oferty pracy (daily)
• zastanowienie się, co jest najbardziej przeszkadzające w pracy i znalezienie sposobu na zlikwidowanie tych barier (retro)
  mają sens.
• nawet szacowanie zadań ma sens, bo pokazuje na ile zespół ogarnia proces i jest to sprawdzenie czy aby wszystko co ma do zrobienia zespół zależy od zespołu.

Problem zaczyna się, kiedy proces staje się ważniejszy niż cała reszta, objawy to:

• nie bierzemy jakiejś nowej historyjki do roboty, bo burndown chart wyjdzie brzydki
• dorobimy testy do historyjki "później", bo burndownchart wyjdzie brzydki
• robimy sobie daily, chociaż komunikacja jest już w pełni płynna np. na slacku i biorą w niej udział wszyscy członkowie zespołu
• "dowieźć sprint" staje się ważniejsze od dostarczenia działającego oprogramowania
• robimy system demo, chociaż absolutnie wszyscy wiedzą, że oprogramowanie działa, albo co gorsza nie działa, ale na system demo pokażemy, że działa
• w każdym sprincie marnujemy klika godzin na wykłady i dyskusje, czym jest story point i dlaczego nie jest to jednostka czasu, chociaż mamy dostarczyć 50 SP co dwa tygodnie
• wykłady, że nie możemy używać narzędzia X, bo scrumowy bóg powiedział, że jest złe i trzeba używać narzędzia Y (np. zależności w Jira są złe, zależności na tablicy są dobre)
• nie można zmienić czegoś tam w procesie, bo scrum guide w punkcie X mówi, że tak nie wolno.

Czyli podsumowując mój punkt widzenia: Agile jest naprawdę fajny, jeżeli rozumie się co on daje, w jaki sposób i jakie ma ograniczenia. Scrum nie jest zły jako narzędzie do oswojenia zespołu z agile. Jeżeli w pewnym momencie zespół jest w stanie podjąć radykalną decyzję typu:
Scrum nam nie odpowiada, bo środowisko jest zbyt dynamiczne, jeżeli coś wpadnie w trakcie sprintu, to możemy to dostarczyć najwcześniej na koniec następnego sprintu, przejdźmy na Kanban, ale zachowajmy sobie kalendarz retro co dwa tygodnie, żeby o tym nie zapomnieć
To mamy do czynienia z ~dojrzałym zespołem pracującym w agile, bo zależy mu na efektywnej pracy, jest w stanie zauważać problemy we własnej organizacji pracy i je samodzielnie rozwiązać.

Zawsze kwicze że śmiechu z tych scrumow. Żadna firma w Polsce nie stosuje tego poprawnie. Amen. Powtarzam, żadna.

na kiedy będzie zrobione to wiadomo, po to są estymacje, które zmieniały się na przestrzeni scrum guide, ale są zawsze, więc jak nie wiesz kiedy będzie coś zrobione, to znaczy że backlog nie jest ready do sprintu, a jak wiesz -> no to wiesz czy to będzie w tym sprincie czy następnym

i już wiesz, że pisze ktoś, kto nie ma pojęcia nie tylko o agile, nie tylko nie widział waterfalla, ale też raczej nigdy nie pracował w projekcie innym niż kopanie rowów
ale zakładam też wersję optymistyczną: pomroczność jasna - można się w dyskusji zapędzić i palnąć coś bez sensu.

Uczciwie oceniając - to bardziej waterfall niż agile. Czy to źle? Niekoniecznie tj. masę oprogramowania tak zrobiono,

Tu w obronie waterfalla - nieprawda. Waterfall nie był nigdy popularny. To zawsze był jakiś promil - mityczne projekty rządowe i czasem powód żartów, czasem zazdrości (że w ogóle tak się da). Nie robiliśmy waterfalla, nawet jak agile manifesto nie było jeszcze nawet napisane.

Waterfall obecnie to wróg publiczny kołczów agilowych, każdy kto nie wierzy w ich brednie automatycznie musi chcieć pracować w waterfallu. Ale to po prostu PRowa bzdura.