Szembejött LinkedIn-en egy bejegyzés, amiben scrum tréninget ajánlanak lassú fejlesztőcsapatok bebikázására. Érdemes a bejegyzést annak kezelni, ami: egy hirdetés. De a gondolatot, amit megfogalmaz, és amibe én is sokszor beleszaladtam, tévesnek, sőt, néha veszélyesnek tartom. Érdemes a témáról hosszabban is beszélgetni, egyáltalán nem a szerző ellen, mint inkább a jelenségre reagálva.
Na igen, a hírhedt scrum. Vagy leginkább a cargo cult scrum, ami elképesztő erővel, gyorsasággal és hatékonysággal oldja meg a meglassult fejlesztőcsapatok problémáit. Rendet vágva a káoszban, villanyt gyújtva a sötétségében.
A TL;DR gondolataimat már egy kommentben leírtam az eredeti poszt alatt:
Szerintem legtöbbször azért lassul be a fejlesztés, mert hirtelen 3 helyett 30 ember akar dolgozni egy olyan kódbázison, amit előtte 8 hónapig reszeltek és amúgy MVP-nek indult, de végül production kód lett.
LinkedIn komment
Ezen a ponton a CEO behoz egy sztárfigurát vagy az ismerősét, akit megváltóként vár az egész csapat. Ő persze nem azzal kezdi, hogy megérti, mi a baj, lépésekben javítja a dolgokat, hanem inkább hoz egy csodálatos módszertant, mint a ✨ SCRUM ✨ ami egyszer már működött valamelyik korábbi projektjén, és azóta kényszeresen-kapaszkodva próbálja máshol is működésre bírni.
Ez kb. 1 évig megy is, az elején óriási sikereket megélve, aztán amikor nagyobb lesz a káosz mint előtte, mert a cég újra nőtt/változott, a felsővezetés úgy rúgja ki a korábban messiásként behozott figurát, hogy felszántja a belsőépítészek által megálmodott office space-t. Ezzel sincs nagy baj amúgy, mert ahogy nő/változik a cég, az igények/elképzelések is változnak, és tuti, hogy ő is teremtett értéket.
Jó dolog a scrum, meg az agilis, meg a lean, meg a scaled agile, meg a minden is, de inkább értsük meg mi hiányzik, lépésekben javítsuk, segítsünk a cégnek iterálni és változást kezelni, abban több a kakaó, mint egy random módszertan ráerőltetésében. 😇
De tegnap óta sokat kattogtam ezen a témán, úgyhogy gondoltam írok róla egy sokkal hosszabb agymenést is.
Képzelt riport egy magyar KKV popfesztivál-szerű munkanapjairól
Elképzelem, hogy most te vagy a CEO ebben a képzeletbeli cégben, és elmondom neked, hogy szerintem mi fog történni, ha fogod magad, és bevezeted a scrumot, még úgy is, hogy egy amúgy profinak tűnő tanácsadó cég segíti majd a munkádat.
És hidd el, elég komoly összegben merek fogadni, hogy a kis szófosásomból sok dolog tényleg így történik majd. Vagy ha úgy olvasod ezt, hogy már túl vagy pár körön, szerintem kényesen rosszul fogod magad érezni, mert PTSD-t okozok neked azzal, hogy kísértetiesen ismerős sztorit írok le.
Szóval túl vagytok a tréningen, mindenki boldog. Az első hetekben csillognak a szemek, meg vagytok mentve, valószínűleg még a Jirát is megveszitek jó sok pénzért az összes extrával. A kávészünetekben megy majd az összemosolygás a tréning zsargonjait koptatva, és ott ül majd a csapat a nagy planning meetingen, talpig scrumban, hogy aztán két hét múlva szomorúan közöljék: sajnos a sprint nem sikerült. A cél sem volt jó, a feladatok sem voltak igazán azok, a taszkosítás sem úgy sikerült, bejött hat hiba, három incidens, négy ASAP kérés. Itt teszem hozzá, hogy a két hét alatt biztos volt legalább egy csupán ötperces feladatod, amivel a PM úgy elzavart, mint terhes macskát egészségügyi sétára, mondván CEO-kám, benne vagyunk a sprintben, hát majd két hét múlva esetleg!
Te meg kedves CEO-m, ezen a ponton akarod kitépni az összes szál hajadat, mert habár hozzávágtál egy zsák pénzt a problémához, az bizony nem hogy nem oldotta meg magát, még rosszabb is lett. Nem mered kimondani, mert remegsz az idegtől, de mélyen belül érzed: ugyanott vagy, ahonnan elindultál.
Oké, oké. Ferdítek-sarkítok, ne vegyél teljesen komolyan. Mert hát nyilván lesz fejlődés, előrelépés, eredmény és bizonyosan siker is. Lesznek örömteli pillanatok, lesznek pozitív változások az előző állapothoz képest.
De a problémát – na, azt pont nem oldottad meg.
Mert mi is a probléma?
Na, ezen a ponton intek mindenkit stratégiai nyugalomra és invitálok egy alapos körülnézésre. Nagyon könnyű beleesni abba a hibába (én sem vagyok szent, meg is tettem sokszor, kérdezz csak meg valakit, aki dolgozott már velem korábban), hogy hozzám vágnak egy problémát, és rögtön az ezeréves szög és kalapács ógörög, négy felvonásos drámájában találom magam, méghozzá főszerepben: azonnal megoldást akarok szállítani.
Teljesen érthető: erősen motivált vagyok, láttam már valamit, ami egészen úgy hápogott, mint ez a kacsának látszó tárgy itt előttem, szeretném megoldani a problémát, úgyhogy hozom is a kacsariasztómat.
De tényleg, ezen a ponton kell megállni, és mielőtt bárki elkezdene megoldásokkal dobálózni, megpróbálni a klasszikus, agyoncsépelt józan ész mentén végiggondolni, hogy mi a baj.
Talán az a baj, hogy tele van a rendszer tech adóssággal? A a csapat összedobott pár hónap alatt egy MVP-t, amivel sosem terveztetek élesbe menni, most meg a rengeteg júzertől roskadozó kóddal szenved az ájtí? Vagy az a baj, hogy míg eddig tizen voltatok az egész cégben, most hirtelen hetvenen lettetek? Hogy amit eddig 3 fejlesztő kalapált, azzal most 30 próbálkozik? Vagy nincsenek elég jó emberek a csapatban? Esetleg eladja a sales, ami még el sem készült? Soroljam még?
Bármi lehet az, de ide a rozsdás bökőt, hogy a csapatmunka, a kommunikáció és a technológiai nehézségek háromszögében lesz az igazság.
De várj csak, erre tényleg megoldás a scrum
Persze. Még az is lehet, hogy te leszel a százból egy, ahol óriásit ugrik a hatékonyság. És az is lehet – sőt, ez egy kicsit valószínűbb –, hogy olyan leszel, mint az egyik nagy magyar telkó, ahol az agilis transzformációból a legtöbb mérnök hónapokig csak annyit érzékelt, hogy a négy különböző rendszer mellett mostmár az ötödikben, a Zsirában is logolni kellett a munkát, és hogy reggelente van valami fura stand-up meeting nevű izé, amiben bent van 30 ember.
Nem a scrum ellen szólok, mert jó módszertan (bár szerintem inkább az építőelemei nagyon jók), de érdemes körülnézni, hogy mit gondol jelenleg a szakma a scrumról, Orosz Geri pár éve nagyon jól leírta a jelenséget.
És érdemes odanyúlni a jó öreg agilis manifesztóhoz is. Volt anno pár ember, akik hasonló problémákra keresték a megoldást, és összeraktak egy szuper kiáltványt, ez volt a veleje a dolognak:
Az egyéneket és a személyes kommunikációt a módszertanokkal és eszközökkel szemben
Kiáltvány az agilis szoftverfejlesztésért, avagy az agilis manifesztó
A működő szoftvert az átfogó dokumentációval szemben
A megrendelővel történő együttműködést a szerződéses egyeztetéssel szemben
A változás iránti készséget a tervek szolgai követésével szemben
Na, hát ők biztosan furcsán néznének most, mert sosem mondták, hogy a scrum, a scaled agile, a lean vagy bármelyik másik módszertan lesz a megoldás a problémákra.
Mi most mégis ott tartunk, hogy ülnek az emberek, és forgatják a fejüket a kéthetes sprintek körül, meg megy a veszekedés, hogy három vagy öt lesz az a sztoripont, pedig mindegy, mert már ott a backlog groomingon, az esztimációnál és a planningen is tudja mindenki, hogy ez legalább három hét meló, csak félnek bevallani. Mert az egész őrület a sprintek körül revolvál.
Nincs recept, nincs mindenre jó módszertan
Nincs tökéletes recept, nincs tökéletes megoldás, nincs mindent vivő módszertan. Fogadd el. Alapelvek, megközelítések, jól bevált taktikák viszont vannak.
A megoldás amúgy annyira nem bonyolult, mégis annyira bonyolítjuk, pedig tényleg ott van az orrunk előtt, hogy mi a legfontosabb:
- a csapat,
- a kommunikáció,
- a működő szoftver,
- az együttműködés,
- és a bátorság a változással szemben.
Ez nem módszertan, ez nem keretrendszer, ez nem kész megoldás. Nem egy tökéletes eszközt akarok neked eladni, csak próbállak visszahúzni az igazság néha fájdalmas, tüskés valóságába. (Ne aggódj, pontosan tudom, mennyire szúr, én is átmentem a cargo cult scrum minden keserédes pillanatán, amíg aztán megérkeztem ide.)
A csapatod és a benne dolgozó egyének gyártják a szoftveredet. A PM és a dizájner is ott ül, helló, nem ám kihagyni őket!
Elengedhetetlen, hogy ezek az emberek folyamatosan és jó minőségben beszélgessenek az ügyfelekkel és házon belül azokkal a csapatokkal, akikkel szükséges. (Az ügyfél lehet a szoftver megrendelője de termékfejlesztés esetén a felhasználója is.)
A működő szoftver azt jelenti, hogy nem rakod fel a bizalmas adataidat GitHubra, hogy kezelhető mennyiségű a technológiai adósságod, hogy érkeznek bele új fejlesztések és így tovább.
Együttműködésre (jó minőségűre) pedig azért van szükséged, mert habár kell a bátorság a változáshoz, de önmagában nem lesz elég. Mert ha belefér tőlem még egy LinkedIn Coelho igazmondás: a változás örök. Tényleg az, és pontosan tudod, mennyire rándul idegbe mindenkinek a gyomra, amikor megérkezik. De közben pont ez a változás csinált az ötfős cégedből ötvenfőset, az ötmilliós bevételedből ötvenmilliósat, az öt feature-ből ötvenet és az öt hibából ötszázat.
Nem akarom neked eladni az agilis manifesztót, nem fizetnek nekem ezért jutalékot, akárhogyan máshogy is megfogalmazhatod, de hidd el, hogy amikor lefekszel ma este aludni, és az ágyadban fekve becsukod a szemed, hogy végiggondold a napodat, ott lesz a fejedben, hogy ezeket a gondolatokat akárhogyan fogalmazod meg, sajnos vagy szerencsére mindig megállják majd a helyüket.
És hidd el, ha csak és kizárólag ezekre a területekre figyelsz, ezeket kezdet nagy erővel rendbe tenni, elégedett leszel az eredményekkel.
Oké, de akkor hogyan vágjak rendet a káoszos, lassú fejlesztőcsapatomban?
Na, amúgy képzeld, pont most kezdek bele egy ilyen tanácsadó bizniszbe, dobj egy hívást és kitaláljuk, hozok valami király módszertant! 😀
A viccet félretéve, értsd meg a problémát. Hogy hogyan? Ülj le beszélgetni az emberekkel. Kérdezd meg tőlük, amit tajtékozva kérdezel magadtól: miért van az, hogy ami két éve két nap volt, most két hónap? Miért van annyi incidens és hiba a rendszerben? De ne csak a fejlesztőkkel ülj le, beszélj szépen mindenkivel. Ha kell, még a takarítóval is, vele lehet, hogy amúgy sem szoktál, és meglepődsz, ha még nála is lesz jó gondolat.
Vezetőnek lenni néha olyan, mint egy Agatha Christie regény főhősének: a sok beszélgetésben kell azonosítanod a visszatérő mintákat és megtalálni az igazságot, ami amúgy mindig ott lesz, mégha elsőre nem is látszódik a sorok között.
Értsd meg mi hiányzik, kezdj el lépésekben javítani, segítsd a csapatodat iterálni és változást kezelni.
Ja, valami gyorsabbra számítottál? Akkor nyugodtan vezesd be a scrumot, fog kapni a csapat egy nitrós löketet, talán 1-1,5 évig menni is fog a szekér, de utána biztos vagyok benne, hogy megint ki fog borulni a bili (mert ugye a változás örök).
Ha viszont kicsit hosszabb időtávra lősz, és amúgy tényleg a problémát szeretnéd megoldani, nem csak gyorsan robbantani, akkor hidd el, ez lesz a jó irány. Aztán ebben nyugodtan kérj segítséget másoktól. Simán lehet, hogy van olyan tanácsadó cég, külső tanácsadó, bölcs szenszei akit fel tudsz venni vezetőnek stb. aki tényleg segíteni fog, már csak azért is, mert külső szemlélőként érkezik.
Csak egyetlen dologra figyelj: nagyon gyorsan rakd magad stratégiai nyugalomba és alaposan nézz körül, amikor valaki jön a kész megoldásokkal, mindent vivő módszertanokkal és tökéletes eszközökkel, de közben még ahhoz sincs elég kontextusa, hogy pontosan megmondja neked, miként is csinál pénzt a cégetek és a terméketek, amiket a csapatoddal évek óta, véretekkel és verítéketekkel építetek.
A borítókép a Pixabay-ről érkezett.
Szólj hozzá!