Cégeteknél van scrum master?

Kérdés

Van, és csak az az egy feladatköre van, hogy scrum master legyen.
7% (24 szavazat)
Van, más jellegű feladatai is vannak, de ideje nagyobb részében látja el scrum masteri kötelezettségeit
5% (15 szavazat)
Van, de ideje nagyobbik felét más kötelezettségeivel (pl. programozás, project manager feladatok) tölti
9% (29 szavazat)
Nincs, egy másik vezető kollega (project manager, lead dev, CTO, etc.) látja el a scrum master feladatkörét
6% (18 szavazat)
Nincs, mert nem használunk scrumot
20% (66 szavazat)
Nincs, mert nincs csapatban programozással foglalkozó munkahelyem/cégem/megrendelőm
4% (14 szavazat)
Mi a bánat az a scrum master?
45% (146 szavazat)
Egyéb, leírom.
3% (10 szavazat)
Összes szavazat: 322

A scrum egy agilis programozasi modszertan, tipikusan 2 hetes sprintekre felosztjak a munkat, ezen belul kiosztjak mindenkinek ki mit csinal, es naponta megbeszelik hogy haladnak. A scrum master kb. ennek a "vezetoje", aki betartatja a feladatokat. Ugy nagyjabol.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Ez most egy rohadt divatos módszer nyugaton, amennyi előnye lehet kb. annyi hátránya is, szóval leginkább bullshit, legalábbis a fogalom.

Amolyan marketing halandzsa, mint az Agil Projectmanagement, és még sorolhatnám.

Egy olyan országban, ahol már lassan munkaerő sincs, nemhogy pénz a gazdaságban, hát nincsenek Scrum masterek.

--
robyboy

Most? Mar legalabb 10 eve meno dolognak szamit, csak ugye a hazai munkaeromorallal nehez rabizni a projektet a csapatra felso koordinacio nelkul, ezert sikeres SCRUM sztorikat nemigen hallani.

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

"a vezetesnek epphogy nagyobb lehetosege van koordinalni, akar 2 hetente uj celokat tuzhet ki..."

Ez a marketing, amivel el szokták adni. Az agile valóban jóval rugalmasabb, hamarabb kiderül, ha csúszás van vagy rossz volt az eredeti elképzelés, és gyakran jobb minőségű a végeredmény is. De ha a vezetés 2 hetente "még fontosabb" feladatokra dobja rá az embereket, sajnos ilyet láttam is, akkor a legrosszabb waterfall is messze felülmúlja mindenben. Az agile a vezetésnek inkább csak kiszámíthatóságra jó, kontrollra nem.

A feladathoz kell választani az eszközt.

A Scrum egy eszköz, vannak feladatok, amikhez jó. Amúgy a 2 hét ugyan gyakori, de egyáltalán nem az egyetlen lehetséges sprint hossz.

Az, hogy sprintenként van egy review és egy planning, az pont, hogy kontrollra jó.
Persze lehet szarul is csinálni.

Van olyan hely, ahol folyamatosan még fontosabb feladatok vannak. Lehet, hogy fejlesztőként kellemetlen ilyen helyen dolgozni, de ha a cégnek ez kell, akkor olyan módszertant választanak, ahol ez megy.

Ha ugy erted, hogy ket hetenkent at kell terni szoftver fejlesztesrol gumikacsa gyartasra aztan onnan autopalya epitesre, akkor persze igy van. Viszont az adott termek fejlesztesenek iranyat igen is akar 2 hetente modositani lehet.

Irok peldat is, hogy ertsuk egymast. A sprintben az a feladat, hogy le kell implementalni a piros gombot, ami elinditja a raketat. A sprintnek vege van, be van mutatva, de akkor a management rajon, hogy megis zold gomb kellene es a raketa mellett inditson el egy uthengert is akkor ezt a kovetkezo sprintre be lehet tervezni, akkor is ha korabban errol nem volt szo. Ez marpedig kontroll, akar 2 hetente.

Nem. A scrum pont arról szól, hogy legalább egy sprint eréjig (2 hét) tartsuk a fókuszt és hagyják békén dolgozni a fejlesztőket. A célok kitűzése pedig folyamatos, ugyanis a korábbi módszertanok pont azért nem működtek, mert abba a tévhitbe ringatták a résztvevőket, hogy képesek 1-2 hónapnál előrébb látni.

A scrum nem bullshit és bizonyos feltételek megléte mellett tökéletesen működik. Mint minden máshoz, ehhez is érteni kell.

Ha betartják a rendkívül szigorú szabályokat, akkor igen, és remekül követhető, ki min dolgozik. Ha eltérnek tőle rendszeresen, akkor csak a felesleges overheadet növeli. Nekem már volt, hogy visszamondtam állást az interjú elején, mert azt mondták, SCRUMban dolgoznak, de két keresztkérdésből kiderült, hogy nem.

A lényeg, hogy nincs mikromenendzsment, és minden csapattag saját maga veszi fel a munkát, és frissíti a státuszát. A túlóra gyakorlatilag tilos, jól összeszokott SCRUM csapat kiválóan tudja becsülni, milyen feladattal mikorra végeznek.
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

A legtöbb cég, ami Agile bevezetése mellett döntött, nem produktívabb team-eket akart, hanem a munkát hatékonyabban szervezni.

Egy fejlesztő nem fog gyorsabban fejleszteni attól, hogy épp Agile módszertannal dolgoznak.

Egy team lehet, hogy gyorsabb lesz, főleg akkor, ha korábban valami problémák hátráltatták őket - az Agile jó abban, hogy a korábban is meglévő problémákat a felszínre hozza, szóval lehet javítani rajtuk.
Egy kiválóan dolgozó team nem lesz produktívabb az Agile-tól, Scrum-tól egy kicsit még akár lassulhat is (Scrum használatával pl. jellemzően több a tervezés, mint korábban).

A scrum egy agilis programozasi modszertan
nem csak programozási...

Nálunk is van napi scrum meeting, amit van hogy én "vezetek".
Ennek ellenére azt pipáltam be, hogy:
"mi a bánat az a scrum master"
ugyanis ezt már akkor is csináltuk, amikor az agilis vallás még nem is "létezett" :D

Szerintem ez az egész "agilis módszertan", pont olyan, mintha a takarítőnőt holnaptól partvis igazgatónak hívnád. Ha pedig ő osztja be melyik klotyót ki és mikor takarítsa, máris scrum master is ;)

Értsd: aki eddig nem tudott hatékonyan dolgozni, az ettől sem fog.

--
zrubi.hu

Hátőőő...

Mivel a mi esetünkben (Security Operation Center) a napi "scrum meeting" lényege, hogy megtudjuk ki milyen problémákkal találkozott, milyen kérdések merültek fel a shiftben. Mi - akik tartjuk ezt a meetinget - pedig igyekszünk ezeket megválaszolni/eszkalálni, és a feljebbről jövő döntéseket, process változásokat, aktualitásokat, stb. ismertetjük a shiftben dongozókkal.

Ezen kvül a napi feladatokhoz lazán kapcsolódó dolgokat is megbeszéljük. Így nem csak száraz unalmas bullshit, hanem sokkal inkább aktív, rendszeres szakmai kommunikáció az, amit ezzel szeretnénk fenntartani...

--
zrubi.hu

"Ha pedig ő osztja be melyik klotyót ki és mikor takarítsa, máris scrum master is ;)"

A scrum master nem oszt ki feladatokat, de teveszted a szokasos team leaddel aki iranyitja a csapatot. SCRUM feltetelezi, hogy a csapat tagjai nagyon aktivak, testtel-lelekkel reszt vesznek a projektben es kuzdenek a sikereert, es nem egy birkanyaj, amit terelgetni kell.

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

"figyel, hogy a jatek szabalyai be legyenek tartva."

Igen. Éz ezek közül is a legfontosabb, hogy indokolatlan hosszú pofázás ne legyen. Nyilván ha egy teljes csapatot érintő témában kitör a brainstorming napi scrumon, azt nem feltétlenül kell elfojtani. De alapból 1 perc után kuss.

"Értsd: aki eddig nem tudott hatékonyan dolgozni, az ettől sem fog."

Az a baj, hogy az agile nem a hatékonyságról szól, hanem a rugalmasságról. Ha az jön ki, hogy hatékonyabb, akkor az pusztán a rugalmasságából kell következzen. Agilis környezetben az egyes résztvevők nem lesznek hatékonyabbak, sőt, sokszor csökken is a termelékenységük.

+1

Agilis környezetben az egyes résztvevők nem lesznek hatékonyabbak, sőt, sokszor csökken is a termelékenységük.

Attól függ, hogy mit hívsz termelékenységnek.
Ha a megírt kód sorok számát, akkor feltétlen igazad van.
Ha az értékteremtést, akkor ebben már nem értenék egyet.

Az agilitásnak éppen az a lényege, hogy a sok felesleges munkát elkerüld.

Az Agilis Kiáltványt alkotó elvek (ide vonatkozó részek):

  • Az agilis eljárások a fenntartható fejlesztést pártolják. Fontos, hogy a szponzorok, a fejlesztők és a felhasználók folytonosan képesek legyenek tartani egy állandó ütemet.
  • A műszaki kiválóság és a jó terv folyamatos szem előtt tartása fokozza az agilitást.
  • Elengedhetetlen az egyszerűség, azaz az elvégezetlen munkamennyiség maximalizálásának művészete.
  • A csapat rendszeresen mérlegeli, hogy miképpen lehet emelni a hatékonyságot, és ehhez hangolja és igazítja az működését.

"Az agilitásnak éppen az a lényege, hogy a sok felesleges munkát elkerüld."

Nem. A legkevesebb felesleges munkát azzal tudod elkerülni, ha mindent előre az utolsó apróságig megtervezel, aztán a tervek mentén kivitelezel mindent. Egyedül ezzel nincs felesleges munka, mindenki pontosan tudja, hogy mikor és mit kell csinálnia. Minden más, ami ettől eltér, felesleges munkával jár, néha csak kevés felesleges munkával, sokszor lényegesen több felesleges munkával.

Nézz meg egy projektet, ha látsz benne törölt sort vagy halott kódot, az felesleges munka volt. Mutass egyetlen egy éles üzemben lévő agilisen fejlesztett alkalmazást, amiben egy sornyi töröld kód nincs és halott kódoktól is mentes...

Látom szerinted mindenre a waterfall a szentírás.

Mutass egy hagyományosan fejlesztett projektet, aminél a fejlesztés után minden funkciót használnak; nem jön be azonnal, sőt a fejlesztés közben új igény, változtatási szándék!

Ilyenekkel teli van az internet, illetve nap, mint nap találkozunk vele:
Are 64% of Features Really Rarely or Never Used?

Nézz meg egy projektet, ha látsz benne törölt sort vagy halott kódot, az felesleges munka volt.

Ilyet hagyományos fejlesztésnél is találsz.
Az a nem törölt kód is felesleges, amit a felhasználók nem használnak.

"Látom szerinted mindenre a waterfall a szentírás."

Nem, sehol nem írtam ezt.

"Ilyet hagyományos fejlesztésnél is találsz."

Igen, találok.

"Az a nem törölt kód is felesleges, amit a felhasználók nem használnak."

Igen, így van.

A "máshol is van ilyen" nem menti fel az agilis projekteket és ott a rugalmasságából adódóan még több ilyen van...

"Mivel nincs tökéletesen, minden üzleti igényt pontosan lefedő specifikáció, és tökéletesen megtervezett kód, ezért mindig lesz törölt sor."

Tudjuk. Viszont agile esetén ezekből még több lesz. Az egy legenda, hogy agilis fejlesztéssel hamarabb le lehet szállítani ugyanazt.

A különbség alapvetően az, hogy ha építeni kell egy szállodát, akkor klasszikus esetben mindent megterveznek az utolsó szögig, felépítenek egy beszállítói gráfot, majd pár hónap alatt teljesen felépítik a szállodát, ám ez egész eltart mondjuk két évig. Ha közben kiderül, hogy a megbízó inkább kollégiumot szeretne vagy lakásokat, akkor szopás van. Akkor is szopás van, ha kiderül, hogy nem lesz pénze befejezni, mert akkor ott marad egy szerkezetkész torzó. De ha szállodát akart, akkor kapott egy fasza szállodát annyiért, amennyiért szerette volna.

Agilis esetben szobáról-szobára építik meg, néha egy egész folyosót lerombolva és újraépítve, de szinte azonnal beköltözhető; majd a végeredmény lehet, hogy egy lakóházzal ötvözött kollégiumi hangulatú szálloda lesz, ami fele akkora, mint amekkorát eredetileg akart a megbízó, mert elfogyott a pénze, de kap valami használhatót a pénzéért. De ha szállodát akart, amiből már ezret felépítettek előtte, akkor nagyon beszopta.

Namost, ha "pontosan" tudod, hogy mit kell szállítani, akkor jó lehet a waterfall.

Viszont ha a specifikációk és requirementek nem teljesen ismertek, csak nagyjából, akkor sajnos a folyosókat újra kell építeni.

Attól is függ, hogy milyen és mekkora a csapat. Jól összeszokott kis cég, vagy állandóan változó csapat több kontinensen?

+1
A waterfall egy ideális világban sokkal hatékonyabb és jobb eredményt produkál, mint az agile. A valós világban ez ritka, bár nem lehetetlen. Az agile pont arról szól, hogy emberek vagyunk, nem tudja a vevő, hogy mit és mikor akar, a feljesztő cégnél meg nem értik, hogy mit szeretne, a tervező félretervez, a kódoló félreérti és hülyeséget csinál, a tesztelő meg másképp érti félre. Az agile valós, hibázó emberekre épít, nem idealizált szuperhősökre. És ezekből termel értéket. Feltéve, hogy a résztvevők érik, hogy mi az agile.

Pl. ilyenek a high-tech fejlesztések, amik még nem voltak a piacon korábban.

Én automotive-ban dolgozom, compute vision területen. Az önvezető kütyük korában a valós követlemények a nem derülnek ki időben. A jelenlegi projectnél pl. a hardver alig van kész, néhány egységére nincs rendes driver, fordító. Sejtjük, hogy mire lesznek képesek az algoritmusok a platformon, de biztosan nem tudjuk.

13 éve vagyok computer vision területen, és ez mindig is igy volt.

Egy híres német gyártó megrendelte a kamerát az autóba, aminek a specifikációja előírta, hogy mi a kamera minimális magassága az úttól. Cserébe a formatervezők letették a kamerát a földre a cég zászlóshaljójánál. így a project vége felé keletkezett egy vadonatúj requirement, miután az egész szoftver átment egy komplett waterfal tervezés, implementálás, teszt cikluson.

Ne csak a kovetelmenyek valtozasara gondolj, hanem arra is, hogy minel hamarabb jo lenne kitolni productionba valami mukodot, meg ha nincs is leimplementalva a funkcionalitas nagyresze. Ez jo, mert mar korai fazisban termelhet hasznot a rendszer, es ugye ha korabban elkezdik hasznalni, akkor korabban kapunk visszajelzest (ami alapjan valtoznak a kovetelmenyek).

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

"Viszont ha a specifikációk és requirementek nem teljesen ismertek, csak nagyjából, akkor sajnos a folyosókat újra kell építeni."

Ahja, teljes mértékben értem. Ezért írtam kicsit korábban, hogy több a felesleges munka, viszont korábban lehet bevételt elérni, illetve kideríteni, hogy egyáltalán működik-e az elképzelés.

Egész jó hasonlat, ahhoz képest, hogy építőipari, pedig már nagyon régi közhely, hogy a szoftverfejlesztés-építőipar, bár gyakori, de nem jó hasonlat. :)

Csak annyi kiegészítés hozzá, hogy agilis esetben, ha szállodát akart és végig azt akar, akkor a végén is szállodát fog kapni. De ilyen soha nincs. :)

Tudjuk. Viszont agile esetén ezekből még több lesz. Az egy legenda, hogy agilis fejlesztéssel hamarabb le lehet szállítani ugyanazt.

Ha legenda alatt azt érted, hogy félreértés, akkor igazad van.

Az Agile manifesztó sehol nem ígéri, hogy bármit hamarabb leszállítanak.

De mégis sokan vannak, akik azt hiszik, hogy ez lesz az eredmény.

"Az agilitásnak éppen az a lényege, hogy a sok felesleges munkát elkerüld."

Nem. A legkevesebb felesleges munkát azzal tudod elkerülni, ha mindent előre az utolsó apróságig megtervezel, aztán a tervek mentén kivitelezel mindent. Egyedül ezzel nincs felesleges munka, mindenki pontosan tudja, hogy mikor és mit kell csinálnia. Minden más, ami ettől eltér, felesleges munkával jár, néha csak kevés felesleges munkával, sokszor lényegesen több felesleges munkával.

Igen is meg nem is.

Egyfelől az agile manifesto nem arról beszél, amiről te, de mindkettő fontos.

Az agile manifesto amikor a felesleges munka elkerüléséről beszél, arra gondol, hogy ne készíts olyan terméket, ami nem kell, amit nem fog senki használni, amitől nem lesz jobb a végeredmény. Gondolhatsz itt olyan optimalizálásra, ami nélkül is jó volt a rendszer, olyan dokumentációra, amit soha senki nem fog elolvasni, olyan funkciókra, ami nem kell a felhasználóknak, stb.

Amiről te beszélsz, az a kísérletezés és a zsákutcák elkerülése. Erre én azt mondom, ha előre tudod, pontosan, hogy mit kell elkészíteni, akkor számodra az Agile nem hoz semmiféle előnyt. Van ilyen projektre példa, de nagyon ritka. Építési projekteknél simán előfordul, hogy ugyanazon terv alapján kell sok házat, hadihajót, elektronikai berendezést gyártani. Előre ki lehet találni, hogy mit hogyan kell és mikor, mi mennyi ideig tart, ki végzi el, stb. De általában a kutatás, a termék- vagy szoftverfejlesztés (vagy bármilyen kreatív tevékenység) nem ilyen.
Ezeknél nem lehet előre megtervezni ennyire részletesen, és nem is érdemes, mert a környezet, a piaci igények megváltozhatnak bármikor - akár holnap, és így a részletes terved elavul, és pont arra lesz példa, amiről az Agile manifesztó beszél. Felesleges munka volt. Az Agile ezekhez az igényekhez passzol.
Itt nem érdekel senkit az, hogy van-e olyan kód, amit törölni kellett, van-e valami, amit többször újraírtak. Nem ez a szempont.

Az utolsó mondatod a SCRUM-mal kapcsolatos félreértések kvinteszenciája :) A SCRUM ugyanis nem cél, hanem eszköz. Nem a hatékonyság növelése a célja, hanem a feladatok követhetősége, becsülhetősége.
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

( ktkt | 2018. 08. 17., p – 18:01 )

Hmm... úgy látom az eddigi szavazatok alapján hogy az IT más területén mozog a többség mint én. :) (vagy le vannak maradva :P)

Hat akkor en (vagy a cegem) nagyon le vagyunk maradva, vagy tenyleg marhara nem hallottam meg ezt a kifejezest... :) Mas kerdes, hogy ez az egesz agilis módszertan teljesen idegen nekem, kb a hup-on olvastam/hallottam rola eloszor.. Akarcsak a DevOps es tarsai...

Amugy fura, mert nem egy garazscegnel dolgozom, kb minden foldreszen van uzemunk, tobb tizezren dolgoznak a cegnel, szoval nyugodtan hivhatjuk "multinak".

Mondjuk teny, hogy ezek nagyresze osszeszerelouzem, de azert van QM, mernokok, IT, etc... mindenhol, de ezeket a kifejezeseket meg csak hirbol sem ismerik a kollegaim...

( zdesigner | 2018. 08. 17., p – 19:03 )

Magunktól is képesek vagyunk betartani a szabályokat.

( tornai | 2018. 08. 17., p – 20:37 )

Van.

De minek. Semmirevaló, ahogy eddig az összes - egy kivételével - akivel dolgom volt. Az az egy sem tudott igazából érdemben semmit sem elérni.

Abból lesz scrum master, aki megunta hogy a sorban ütögeti a kódot és úgy gondolja hogy most akkor ő manager lesz - mert programozni 35 évesen már nem menő. Ha 35 évesen még kódhoz kell nyúlnod, akkor szégyen van... Kivételt még nem láttam.

Egy sem fogja ezt bevallani. :)

A szavazas azert lett kiirva, mert nekem egy elo maganbeszelgetesben ugy elo lett adva hogy "kell egy scrum master, akinek semmi mas dolga nincs csak full time scrum masternek lenni". Aztan egy masik tole tok idegentol is hallottam ugyanezt. Mindketto amugy jo programozo, akik ezt mondtak (de egyik se ilyen kornyezetben dolgozott, ahol full time scrum master van, csak "ugy kene lennie"). Kivancsi voltam, hanyaknal mukodik ez igy.

Ahogy elnezem a szavazok <30%-at erinti a szavazas, kevesebb mint 30% programozik olyan helyen, ahol scrumot hasznalnak.

Szerintem 1 csapatban Scrum Masternek lenni nem egy teljes munkaidős tevékenység. Vagy ott valami gáz van.

Láttam arra példát, hogy osztott szerep volt: Scrum Master + BA, Scrum Master + tesztelő vagy fejlesztő, meg láttam arra is példát, hogy egy Scrum Master több csapatot is vitt - és nem volt más szerepe.

Mi is egy SM feladata? Mert azon kívül, hogy bénáznak a meetingek szervezésével/vezetésével (holott sem a bizniszt, sem a technológiát nem ismerik) és olyan retrókat tartanak, amiknek semmi értelme... az én szememben egy SM egy sima költséghely/kolonc/eltartott.

SM nélkül is klasszul meg tudják beszélni az emberek, hogy mi a feladat meg mik a határidők és mik a fontos dolgok - mi több, ha elkezd félremenni egy megbeszélés, akkor én/mi is képesek vagyunk hiphop felhívni az emberek figyelmét, hogy ezt talán nem most kéne. Amikor pedig egy fos csapat nem működött valahogy így, akkor hiába volt dedikált (egy másik csapattal megosztott SM), ugyanúgy szarul működött az egész és vergődés volt meg felmondási hullám/kirúgások/hisztik... (példa: 16ból 8 ember felmondott 5 hónap alatt)

Egyszerűen nem értem, hogy nem full kretének mellé minek egy ilyen pozi. A full kreténeket meg ki kell tenni az utcára.

Tudom, hogy a könyv szerint mi egy SM feladata, de a valóságban ezt nem láttam megvalósulni. ~8 évet lenyomtam agilis scrum csapatokban és ~10 különböző SM-hez volt szerencsém. Persze az ügyfeleknél lehet hogy most ez ilyen varázsszó és el lehet őket parasztvakítani. :)

SM legyen az egyik csapattag. Csapatoknal, akiknek uj a SCRUM, van ertelme egy erre szakosodott embert hozzaadni, de az inkabb "agile coach", "agile consultant".

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

En ebben a szalban vegig a "semmittevo" scrum masterrol irtam. Egy onallo SCRUM csapatban nem kene annyi feladata legyen, hogy teljes munkaidejet kitoltse az SM szerepkor, ahol ez tortenik, ott szerintem a hagyomanyos team lead / PM-et neveztek at, aki terelgeti a nyajat, ezert nem SCRUM ami ott folyik, a csapat picit sem onszervezo.

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

Csapatoknal, akiknek uj a SCRUM, van ertelme egy erre szakosodott embert hozzaadni, de az inkabb "agile coach", "agile consultant".

Nem értek egyet.

Lehet, Agile Coach-ot hívni, de egy kezdő csapathoz szerintem felesleges, ugyanazt fogja csinálni, mint ami a Scrum Master szerepe lenne: oktatással kezd, lefekteti az induló folyamatokat, aztán szigorú játékvezetőként felügyeli a csapatot, amíg az emberek bele nem tanulnak a módszertan keretein belüli játékba.

Az Agile Consultant teljesen más (az én olvasatomban), nem a csapatok szintjén dolgozik.

Scrumguides.org, 19 oldal. Van magyarul is.
A Scrum az egy keretrendszer: ad egy csomó lehetőséget az adaptációra - mint minden jó keretrendszer.
A helyes implementáció pedig az, hogy vagy betartod a keretrendszer szabályait teljesen, vagy ha mégsem akkor nagyon tudatosan - célszerű leírni - mérlegelve az előnyöket és a hátrányokat, változtatsz.

--
Gábriel Ákos

Erre semmiképp nem fogsz értelmes választ kapni, mert a SM ténykedése a csapattól függ.

Egy jól működő, önszerveződő csapatnál az SM feladata az, hogy szóljon felfele, ha a tervezett határidők és a valóság valamelyik irányba kezd nagyon eltérni. Magyarán heti pár perc munka, bármelyik csapattag elvállalhatja.

Egy olyan csapatban, ahol totál összefüggéstelenül elkódolgatnak az emberek, ahelyett, hogy értékes terméket adnának ki a kezeik közül, ott bizony segíteni kell megtalálni a fókuszt és napi 2-3 óra munkája is lehet egy csapattal és érdemes emiatt külön embert fenntartani. (A nap többi részében is biztos akad neki munka.) És ilyenkor még fontosabb a retró, hogy előjöjjenek a jó ötletek a hatékonyság növelésére.

Leginkább a PM feladata kezelni a helyzetet. De honnan tudná, hogy helyzet van? A napi scrumon még csirkeként sem feltétlenül szerencsés a jelenléte. És a toolokból sem látja, mert jobb esetben cetlik mennek a táblán. A toolok ugyanis a kényelmetlenségük miatt elég rossz hatással vannak a csapat működésére.

Kell lennie egy architect-nek a csapatban, aki átlátja a státuszt és szükség esetén riportál neki.

A jó PM lehet, hogy korbáccsal kerget, de ez a másik irányba is igaz: ahol tudja segíti a munkád, egyezkedik a megrendelővel, ha valamit nem, vagy a haszonhoz képest irreálisan magas költséggel lehet csak megoldani.
Szóval ő téged is képvisel.

Kell lennie egy architect-nek a csapatban

Dehogy kell!

aki átlátja a státuszt és szükség esetén riportál neki.

Vagy lehet, hogy félreértettelek, szóval betennél egy embert a team-be, elnevezed architect-nek, és semmi mást nem csinál, csak annak egy kis részét, amit a Scrum Master egyébként is megtesz / a PM is simán megtehetne (ha van PM)

Fura elképzelés.

Nem értem, hogy ez miért lenne jobb, az eddigi projektjeinkben nem volt szükség ilyen pozícióra.

Érdekes.

Szerintem a napi scrum meeting nyílt, és bárki beállhat oda hallgatózni, akit érdekel. Pl. a PO, vagy PM ha van.

Másfelől a fizikai tábla a cetlikkel pont azért jobb (szerintem), mint a toolok, mert _bárki_ láthatja azt, hogy mi a helyzet, nem csak az, aki tudja az adott toolt használni, van felhasználója, tudja az URL-t.

Ha a PM ránézve a táblára nem látja, hogy gáz van, akkor a tábla nem jól működik (nem a megfelelő információ van rajta vagy nem a megfelelő módon van az ábrázolva)

helytelen dolgok, antipatternek (fejből, és csak amit láttam):

- storypointok átváltása órára, pénzre
- retro elhagyása
- csapat kettéosztása backend-frontend csapatokra, nem megtartva a cross-functional-team szerkezetet
- hibajavításra nincs timebox definiálva de a velocity elvárás megmarad (giga stressz)
- tesztautomatizálás megspórolása
- daily standup átalakítása bug megbeszélés meetinggé

Ezek nem mind a scrum master hibái - sok mindent a felső vezetés erőszakolt a projektre - de az, hogy hagyta, az már igen.
A SM és PO szerep is elég sok konfliktus felvállalásával jár (a management felé), ahogy oktatáson mondták is: a PO dolga hogy éppen annyi konfliktust vállaljon fel, hogy ne rúgják ki - mert ha kirúgják akkor nem tud a csapat hasznára lenni.

--
Gábriel Ákos

A retro az, ahol egy SM irdatlan sokat tud tenni a csapatért, a projekt sikeréért.
Nekem volt egy SM-em aki valami zseniális volt a retrókon, igazából miatta volt sikeres az egész és miatta kezdtem el komolyabban foglalkozni scrum-mal.

A retro arra jó, hogy a SM kihúzza a csapatból (legyenek akármilyen introvertáltak és/vagy ellenségesek) azt, hogy mit gondolnak a legnagyobb akadálynak a munkában, mi lenne a leghasznosabb a projektben.
Ehhez kell egy bizalmi légkör, ezt is meg kell teremteni.

set the stage - gather facts

Utána megszületik a megegyezés hogy mi legyen a fókuszban, mi az a 3 a csapat számára konszenzusosan legfontosabb dolog amin változtatni kell.

create insight

Megállapítjuk h mi az ami csapaton kívüli akadály és/vagy mi az amit a csapat önállóan meg tud tenni.
Legyen ez definition-of-done változtatás vagy bármi egyéb.

A csapaton kívüli akadályok elhárítása a SM dolga.
A csapaton belüli teendőkre pedig születik egy megállapodás, hogy ki/kik mit tesznek a következő sprintben.

Szóval pont a retro az a fórum ahol a Scrum kereteken belüli agilitás, adaptáció megvalósul.
Ezt elhagyni gyakorlatilag megöli a Scrumot.
--
Gábriel Ákos

"- hibajavításra nincs timebox definiálva de a velocity elvárás megmarad (giga stressz)"

Elöljáróban: kívülállóként, de őszinte érdeklődéssel olvasom ezeket a hozzászólásokat.

Ha jól veszem ki, az idézett részletben annyit mondasz, hogy a fejlesztőtől kvázi lehetetlent kívánnak egy adott szituációban az értelmetlen szervezés miatt.

Mindig érdekelt, hogy ilyenkor "mi van". Mi történik, ha a programozó "giga stressz" helyett annyit mond, hogy ezt nem lehet megoldani, és mondjuk mellé nyugodtan el is magyarázza, hogy miért nem?

Egy anekdota szerint Einsteinnek egyszer egy száguldó riporter nekiszegezte a kérdést:

"Mester, el tudná nekünk 20 másodpercben magyarázni a relativitáselmélet lényegét?"

Erre Einstein kényelmesen hátradőlt, gondolkodott 20 másodpercet, aztán annyit modott:

"Nem."

És ennyi volt az interjú.

Mi van, ha agilis Scrum Master jobbra, definiálatlan timebox balra, a programozó hátradől?

---
Science for fun...

Ha jól tudom, a scrumban taskok vannak, annak pedig becsült hátralévő óraszámai. Ha a fejlesztő maga becsült mellé, akkor nevethet egy jót magán, ha más, akkor meg szidhatja. Mindenesetre a hátralévő időt nyugodtan felfele is változtathatja, legalább látják idejekorán az érintettek, hogy csúszás lesz. De azzal együtt kell tudni élni, hogy a hibajavítás nem igazán jól becsülhető. Egy kicsi stressz belefér, sok nem.

A probléma a Velocity elvárás.

1, ha valamit mérünk, azzal megváltoztatjuk a rendszert. Ha a velocity az, amit mérünk, és amit elvárunk, akkor a rendszer meg fog úgy változni, hogy megkapjuk az elvárt számot, de am már nem az lesz, amit korábban jelentett.
2, teljesen normális az, hogy a velocity nem állandó.

Mit tehet ilyenkor egy team:
Tervezéskor annyi fejlesztést vesz fel, amennyit le tud szállítani. Kevesebb lesz, mint korábban.

Mit tehet ilyenkor egy Scrum Master:
1, oktatja azokat, akik nem értik, hogy mi az a velocity és mire jó
2, megvédi a team-et a planning meeting során - leállítja azokat, akik tolni akarják a munkát a csapatra.
3, a planning után is megvédi a csapatot, ha jön mindenféle fejes hőbörögni, és goto 1

Igen, a legtöbbször pont az a baj, hogy az adott agilis módszertant (pl. Scrum) megpróbálják kőkeményen betartani, mindig ugyanúgy, változatlan szabályokkal. Holott az agilitásnak épp az az egyik legfontosabb pontja, hogy ne a módszertanok és az eszközök legyenek a meghatározók! Lásd agile manifesto.

Aki elolvassa a Scrum guide-ot (lécci olvassátok el!) az rájön, hogy pont az egyik szabály az, hogy a retro alkalmával döntéseket hozunk arról, hogy x y dolgot másképp csinálunk a jövőben.
Ezáltal nem a Scrum szabályaitól tértünk el, hanem a saját korábbi szabályainktól.

--
Gábriel Ákos

A Scrum Masternek három fő feladata van:
1) Facilitation, aminek nagy része a meetingek szervezése, vezetése. Nem szakmailag vezetik a meetinget, hanem biztosítják azt, hogy mindenki kapjon szót, egy beszélgetés follyék egy időben, a témánál maradjanak, az betervezett időbe beleférjen és legyen valami eredménye. Ahogy fent írta valaki, mint egy bíró a focimeccsen.
Ha a retrónak nincs értelme, az baj. Lehet a SM hibája is, de lehet a csapaté is. Vagy a környezeté. Mindenesetre a retró fontos, és szomorú, ha nem működik.
2) Akadályok elhárításának koordinálása - ő maga is elháríthat dolgokat, de a fő felelősség az, hogy minden akadálynak legyen meg a felelőse és kövessük, hogy van-e előrelépés
3) a team tanítása, ebbe sokan sokfélét értenek, szerintem főleg Scrum keretrendszer tanítása, főleg kezdő csapat esetén, illetve Agile gondolkodás tanítása Scrumban otthonos csapat esetén.

A harmadik pont az, ami hatására elméletileg a kreténekből is válhatnának értelmes emberek. És igazad van, nem kell mindenhová Scrum Master, ahogy Scrum sem. A Scrum egy eszköz. Mint minden eszköz, van amire jó, és van, amire nem jó. Ha a csapatnak nem kell Scrum, használhat más (akár saját) megoldást. Ha nincs Scrum, nincs Scrum master sem. Ha nincs szükség ezekre a tevékenységekre, akkor nem kell rá ember. De ha van, mert valakinek csak létre kell hoznia a meetingeket a közös naptárban, meg felírni a cetlire, hogy milyen akadályokat kéne elhárítani, akkor meg úgyis lesz ember, aki ezt elvégzi, és teljesen mindegy, hogy Sctrum Masternek, Team Facilitatornak, Lead Developrenek vagy Józsinak hívjátok.

Láttam már olyat, aki tudott programozni is és sok máshoz is értett, s scrum master volt. Na vele élmény volt a munka. Viszont őt be is fogták mindenféle más munkára is, magyar cégnél nincs elég szándék vagy fedezet, kapacitás arra, hogy legyen külön ember.

De nyugatabbra, ahol nem mindenesek az emberek, ott a PO és a scrum master semmit sem ért a programozásból. 100 fős cégnél van úgy 10 po és 5 agilos.

Ez az úgynevezett Enterprise Agile.

Általában az a probléma, hogy nagy cégeknél jön egy parancs, hogy holnaptól agilisek lesztek és holnaptól mindenki agilis. Na, lófaszt lesz agilis. Megtartják a daily stand up megbeszélést 5 perc alatt, ahol minden mindig tökéletes, aztán először hetente, aztán két hetente végül havonta terveznek sprint-et, ami egyre inkább pont olyan, mintha egy kicsi waterfall lenne, egyre inkább öt perc pontossággal becsült feladatokkal, aztán csinálnak mindent úgy, mint régen. Közben az üzlet vérszemet kap, hogy minden megcsináltathat azonnal a fejlesztőkkel, így tényleg mindent megcsináltat, legyen az bármilyen faszság, mert ugye üzleti értéket nem mérnek vissza, mert visszamérni is faszság, persze hogy dőlni fog a pénz, ha egy gomb máshol van, minek azt visszamérni. Persze nem ülnek egy helyen a projekttagok, mert az milyen faszság, hogy ezért ürítsenek ki egy tárgyalót vagy építsék át az egész emeletet, jó lesz mindenki ott, ahol van, elég, ha a daily stand up öt percében látják egymást, majd írnak emailt és olvassák a doksikat. Persze, mivel nem ülnek búra alatt és mindenkinek van még 10 feladata, amit nem lehet róluk levenni, mert akkor ki csinálná, ezért 15 százalékban lesznek agilisek, a többi 85 százalékban meg nem, ezért aztán mindig vadászni kell a projekttagoknak megfelelő időt a megbeszélésekre, mert soha nincs olyan idő, ami mindenkinek jó.

( prion | 2018. 08. 18., szo – 13:48 )

én lennék az :D milyen kell ehhez amúgy, hogy valaki főfoglalkozású ez legyen?

hát elvileg ehhez is vannak képzések / továbbképzések meg certek. Az elvetemültebb feljesztők is csak nagyjából szokták sejteni, én meg örülök, ha ismerem a folyamatot, de nem kell a kitalálásában részt vennem. Ahol bőven van kapacitás ezekre, ott meg már néha mintha túl is burjánzanának, avagy nem örülök annak, ha havonta változik a folyamat, mert kísérleteznek.

( blalo | 2018. 08. 21., k – 10:29 )

A "van csak nem így hívják" lehetőség kimaradt.

( igor | 2018. 08. 28., k – 09:58 )

Dedikált SM-ünk van két scrum teamre.

A mi scrum masterünk nagyon profi. Szerintem ahhoz, hogy ez jól működjön, kell egy ehhez passzoló személyiség, mert ez nem a számonkérésről szól, hanem koordinációról.
Mi SM-ünk nagyon összefogja a csapatokat, kb olyan mintha egy edző lenne. Hozzá kell tenni, hogy vízilabdás volt.

Kb 8 éve szintén volt SM más cégnél, ő is hasonlóan megnyerő volt és ott is nagyon jól működött.