Van pár hozzávaló, amiről sokan azt hisszük, hogy kipipáltuk a listánkon, de tévedtünk. Amit annak ellenére, hogy az Agile egyik alappillére, az iterációközpontú gondolkodás még mindig pimaszságnak ítél meg, ha használni akarjuk. És amit ha csak félig értünk meg, az a csapatunk lassú halálához vezet.
Scrum-ozunk, de mégsem
Az utóbbi években feltűnően megszaporodott azoknak az eseteknek a száma, amikor egy vállalat a saját „alternatív” Scrum-járól számol be – némileg átírva a Scrum Guide-ot, ezt-azt áthúzva, törölve belőle – majd tovább mennek egy lépéssel, és azt mondják: „Igazából agilisak vagyunk, hasonlítunk a Scrum-ra, de saját folyamatunk van.”
Ezt önmagában egy teljesen normális jelenségnek, sőt magának a távoljövő megfelelő irányzatának tartom, hiszen a százszázalékos szervezeti egyediesítés az alapja az igazi folyamatfejlesztésnek.
De. Nem mindegy, hogy hogyan kezdünk neki. A hosszútávú szervezeti tapasztalatszerzés és az egészséges agilis- módszertani szárnypróbálgatások mellett van ugyanis ennek egy csöppet sem eredményes, elsietett módja is: számos tapasztalatlan cég felsővezetése kinéz a „katalógusból” egy „trendi” működési struktúrát, majd kiadja egy Scrum-tankönyv bemagoltatását úgy, hogy hírből sem ismeri az Agilis transzformáció fogalmát, felületesen átpörgeti a lapjait, majd egy év sikertelenség és kudarcélmény után úgy dönt, hogy inkább kontár módon átszabja magát a Scrum Guide-ot, mert az alkalmazottak valamiért nem voltak vevők rá. És mire kettőt pislognak, szigorú módszertant gyártanak egy olyan keretrendszerből, aminek sosem szabadna módszertanná válnia.
Vajon hagytak maguknak időt arra, hogy megtudják, pontosan miért nem működik náluk a „gyári” Scrum, és ténylegesen alternatív folyamatra van szükségük? Nem, eddig a kérdésig el sem jutottak. Csak egy dolog tudatosult bennük: egyszerűen nem működnek. A matek kijön, pénzük még van, de romlik a minőség és a munkamorál, és szállíngóznak el a fejlesztők.
Tehát egy valami élesen kirajzolódik:
Valamit még mindig nem értünk elég jól az Agile-értékrendből, ezért a Scrum-unk sem hasít.
… ezért saját megoldás után kutatunk, de a „visszanézés” és az Agile-alapelvek elővétele helyett még gyakran inkább előre rohanunk, és hajlamosak vagyunk továbbrontani a helyzetünket. Ugyanis ha valami nem romlott el, azt nem kell megjavítani. És közel sem biztos, hogy az eredeti projektrendszerünk elromlott, simán lehet, hogy csak nem értjük jól az értékrendjét. Vagy legszélsőségesebb esetben gőzünk sincs róla, mi jelent az „Agile„.
A maximum nyomatékon pörgő motor
És habár a problémakör nem rendszer-specifikus, ismertsége okán mégis a Scrum-on keresztül érzékeltetem azt: ha csak simán a saját fogalmi dimenziójában, burokban és vakon pörgetünk egy módszertant vagy keretrendszert, akkor az rövidtávon brutális termelékenységet hozhat, de hosszú távon pont az ellenkezőjét érjük el vele. Hiszen a Scrum a saját fogalomkörében a „tökéletesség művészetének” illúzióját kelti, mivel a Guide igyekszik lefedni a szakmai és emberi problémaforrások teljes egészét,
ezáltal ha csak önmagában, valódi emberi felügyelet nélkül hagyjuk működni, akkor olyanná válik, mint egy folyamatosan a maximum nyomatékát leadó gépjármű. Kettesben húz mint az ‘állat, de ha nem használjuk a sebességváltót megfelelően, előbb utóbb taccsra tesszük az egész motorblokkot.
Gondoljuk csak végig mi szakmabeliek, hányszor hallottuk már a kívülálló ismerősöktől, hogy „ők már attól rosszul lennének, ha csak simán kéthetes periódusokra lenne felosztva az életük és minden egyes reggel standup-olni kellene, hogy bírjuk ezt lelkierővel”. Hallottuk jó sokszor, bár mi magunk ritkán vesszük észre milyen ritmusban jár az agyunk, hiszen benne élünk.
És valóban, utóbbi a példa arra, amikor a Scrum rosszul működik, és nincs megfelelő és szakértői HR-kontroll felette. Hibásan működve a Scrum ugyanis úgy fogyasztja az embereit, mint a gépjármű az üzemanyagot: kap egy teli tankot, két év után kiégeti és a kipufogóján kiköpi magából az emberi erőforrást, majd a következő benzinkúton újratankol, és száguld tovább alacsony fokozaton-magas nyomatékon, hogy jó hangosnak, trendinek és menő sportverdának tűnjön.
De nem a Scrum a bűnös. Hiszen pontosan az Agile Manifesto-ban taglalt változás iránti képesség, mint alapelv adja ki azt az utasítást a Scrum-nak, hogy ne hagyja magát távolsodródni a másik alapelvtől, az egyénközpontúságtól.
„Nem értem. Ha fontosak nekünk az emberi értékek, miért lépnek le?”
Mert pont, hogy nem értjük. Az emberi lény alaptermészete a szabálykönyvek és módszertanok definíciós ellentéte. Ez nem jelenti azt, hogy az ember nem tud egy cél elérése érdekében szabályt követni. De figyelembe kell vennünk, amikor az embert működési keretek közé tereljük. És totális tévúton járunk, ha azt gondoljuk, hogy az emberi lény kíváncsi-problémás természete a retrospektívek, a daily standupok és a önálló user story vállalások miatt fog kiteljesedni. Ezek a fogalmak mind ugyanis egy dolgot szolgálnak: a pénzt. És igen, némileg pőrén hangzik, de kicsit tegyük félre a motivációs bullshit-generátorunkat, akkor is igaz lesz: ez a szabályrendszer az üzletet szolgálja ki, és habár a saját gépezetét olajozottá teheti az emberközeli értékrenddel, a genetikai kódja akkor is az ügyfél pénzéről szól. És ez így van jól, ebben nem hibás a Scrum, hiszen mi más feladata lenne egy munkahelyen, mint segíteni a pénzkeresésben?
És egészen addig, amíg kizárólag az üzleti keretek között (azaz a Scrum-események keretein belül) beszélünk meg problémákat, addig esélyünk sincs rá, hogy az emberi problémáinkat 100%-osan feloldjuk, még ha 99-ig el is tudunk araszolni. Mert az emberi lélek nem anyagi alapon működik, ezáltal tudatalatt örökké hagyni fog egy lépés távolságot a Scrum irányába, bármennyire is tudjuk, hogy a retrospektíven elvileg „mindennek ki kell jönnie”. Úgysem fog. Sosem fog, és csak áltatjuk magunkat, ha azt gondoljuk, hogy a csapatunk egyszer elérheti azt a szintet.
Az emberben van egy tudatalatti, ősi szupererő, ami arra szolgál, hogy kiszúrja a szabályos mintázatokat, ismétlődéseket, másnéven: a természetellenességet.
Számos tudományos és művészeti (főleg zeneesztétikai) kutatás is bebizonyította a múlt században, hogy az ember alaptermészetéből fakadóan képtelen élvezni a túl tökéletes mintákat, a matematikailag közel tökéletes hangmagasságokat, és ahogyan ez az igazság a művészet minden ágára igaz, úgy természetesen az ember saját élőkörnyezetére is. Több százezer éve kódolva van bennünk a túlélés érdekében, hogy a természetközeli életünk fenttartása érdekében vonzódjunk is a tökéletlen természethez. Első blikkre hiába ad minden emberi problémára választ a retro és a standup, az ember akár tudatosan, akár tudatalatt akkor is érzékelni fogja, hogy ez egy minta, ami minden nap megtörténik. Tudom, hogy két hét múlva lesz egy retro. Tudom, hogy egy hónap múlva akkor is lesz egy retro. Sőt, ha ránézek a naptárra, azt is tudom, hogy a jelenlegi iteráltság szerint egy év múlva ilyenkor milyen sprinteseményt fogunk tartani, és hogy addig legalább 250 reggeli standupon fogok részt venni. Egy ilyen intenzíven iterált és monoton környezetben egy egészséges ember átlagosan 2-3 évet tud csak eltölteni személyiség vagy motiváció-károsodás nélkül. Az, hogy egy munkavállalót ilyen viszonylatban egy életre tartsunk meg, az teljességgel lehetetlen, nem csak hogy nem azt a kort éljük már, hanem ráadásul az IT-szektorban is dolgozunk.
A kiszámíthatatlanság gyógyító ereje
Nem véletlenül épülnek a modern és agilis útmutatók rövid és emberi aggyal felfogható léptékű értékszállításra, sprintfordulókra és ügyféldemókra. Mert nem csak ügyfél számára hasznos, hanem a fejlesztő számára is könnyebb érzékelni és értékelni egy problémát, amire megoldást kell gyártania. Könnyebb motiváltan dolgozni, ha a „big picture” kisebb lépésekre van felosztva, és egy fejlesztőnek (amellett, hogy értenie kell) minél kevesebbet kelljen agyalnia azon, hogy mi lesz a projekttel, ha az egész leszállításra kerül egy év múlva. De ha a csapat mellett nem dolgozik egy szakértő HR-es, coach vagy szakmailag széles tudásspektrumú SM vagy PO, akkor nem tudatosul senkiben sem, hogy ez a motiváció csak egy ideig működik, aztán a túl szabályos módszertani minták okán átveszi az uralmat a monotónia érzése, és puff, ki is égett a fejlesztő, mint a villanykörte. Ennek elkerüléséhez első körben meg kell értenünk, hogy a Scrum nem egy szigorú lépésekból építkező módszertan, hanem egy fix készlettel rendelkező keretrendszer, amely a skálázhatóságából fakadóan „gyárilag” elég szabadságot biztosít számunkra, hogy egészséges módon fenn tudjuk tartani a működését.
Tehát kell egy olyan szakember a csapat mellé, aki megszakítja a monoton munkarendet.
És nem is akárhogy, hanem kiszámíthatatlanul. Tudni kell úgy felülről menedzselni egy Scrum team-et, hogy azt mondjuk: „Szerda délelőtt ne dolgozzon senki, kimegyünk dumálni a teraszra. Nem retrospektív lesz, csak úgy.” Például. De álljunk meg egy pillanatra: nem leszerződtetünk X. hó csütörtök-péntekére egy csapatépítő céget, hanem valódi és természetes kiszámíthatatlanságot, vagyis a természetes emberi működés receptjét keverjük bele a gépezetünkbe. Lássunk még pár ötletet..
- Ha úgy érezzük, hogy a csapatnak a túl egyenletes iteráltság a kényelmetlen (mert van ilyen csapat), akkor ne pörgessünk éveken keresztül kizárólag kéthetes sprinteket. Néha legyenek másfél, háromhetes, de ritkábban akár lehetnek max egyhónapos sprintek is.
- Hiába „ütötték” belénk az ellenkezőjét, igenis előfordulhat az univerzumban néha olyan esemény, ami miatt el kell hagyni az aznapi standup-ot.
- Ha úgy ítéljük meg, hogy a retrospektívet szakmai okok miatt nem szabad megtartani, vagy a csapat egy aktuális probléma miatt nem lenne képes effektíven végigcsinálni, akkor nem tartjuk meg. Nem erőltetjük rájuk, helyette alternatív megoldást keresünk.
- A „rugalmas munkaidőnk” ne csak a szokásos kamu legyen, hanem valóban adjuk meg a lehetőséget, hogyha a fejlesztő délután fáradt, és ő este akarja folytatni a munkát, akkor bátran tegyen így.
- Stb.
Miért ne lennének a fentiek megvalósíthatók? Nyilvánvalóan számos agilis vezető fibrillál és fuldokolni kezd nagy érthetetlensége okán, ha ilyesmit olvas, de nem kell ezektől félni. Az emberiség nem múlt hét hétfőn találta fel a pénzkeresés nevű tevékenységet, hanem többezer év óta úzzük, és nem haltunk bele sosem, ha kicsit eltértünk a szabályoktól.
Csak addig legyünk rugalmasak, amíg a Scrum Scrum marad
Ennek a cikknek a fő mondandója tehát abból az esetből táplálkozik, amikor egy csapat számára már adott egy jól kitanult Scrum, az egyének ismerik a minimum elvárásokat, határokat, szerepeket, de mégis hajlamosak elfelejteni, hogy a szabályokat lehet néha oly módon is tágítani, hogy azok ne veszítsék el funkciójukat. Pont ettől beszélünk keretrendszerről, nem pedig módszertani törvénykönyvről.
Van azonban egy akadály. A témában forgó „Scrum-rugalmasításhoz” egy velejéig agilissá fejlődött cég, vérprofi agilis menedzserek és vezetők szükségesek, pár alkalmas SM vagy PO kurzusról „kiesett” kollégák azonnal elvéreznének egy ilyen típusú folyamatfejlesztésben. Ennek oka, hogy kizárólag sokat látott és tapasztalt szakembereknek van meg az a gyakorlati és lexikális tudása, amivel fent tudják tartani az egyensúlyt egy „rugalmasított Scrum”, és aközött, hogy a keretrendszer ne veszítse el a lényegét, és továbbra is Scrum-ról beszélhessünk. Sajnos a piacon elterjedt betegségnek számít az is, hogy szakmailag felkészületlen vezetők olyan jelentősen szabnak át egy Scrum-ot, hogy annak ellenére is Scrum-nak hívják, hogy már régóta semmi köze sincs a keretrendszerhez, és a benne lévő fékek-ellensúlyok rendszere már réges régen megbukott. És mikor rákérdezünk, hogy „Akkor pontosan miért is gondoljátok, hogy Scrum-ban működtök?”, akkor az a válasz érkezik, hogy „Szeretjük a sprinteket, mert gyorsak”. (megtörtént eset alapján)
Tehát jó dolog az, ha egyedi szabályokat gyártunk a Scrum alapján, de sosem fogunk tudni működő szabályrendszert összelegózni, ha nem ismerjük az agilis-filozófia minden csínját-bínját.
Azonban hiába csak a legtapasztaltabb cégek és szakemberek alkalmasak arra, hogy tehetségesen kihasználják a Scrum mozgásterét és szabadságát, ez nem jelenti azt, hogy sokan közülük könnyen is nyitnának a szabad-szelleműség felé.
– Jó, de mikor térül meg a projektben, amikor elengedtem őket hamarabb? Ki fogja megfizetni, ha a meg-nem tartott standup miatt nem jön elő egy bug?
– hangzik el a kérdés minden nívódó agilis vezető fejében. A projektmenedzsmentnek még klasszikus formájában is mindig megvolt erre a bonyolult válasza: jól kell tervezni. Még ha a csapat nem is tud róla, nekünk be kell tervezni az ismeretleneket az egyetlenbe. Rá kell rakni azt a „pluszt” az erőforrástervezés során, annyit megérdemel a csapat, és ez kivitelezhető úgy is, hogy nem veszítjük el a következetességünket és a néha szükséges szigort.
Ha a Scrum amúgy kompatibilis a csapatunkkal, de egy idő után nem szállít ugyanúgy eredményt, nem átalakítani kell azt, hanem nyitottnak kell lenni a változások felé és tudatosítani kell magunkban, hogy hiába képes precízen működő gépezetként száguldani egy módszer/keretrendszer, néha tudnunk kell elvenni a lábunkat a gázról, hogy majd egy kis szünet után újra beletaposhassunk.
Akármennyire is magas fordulatszámú a szakmai közeg, amelyben élünk, úgy hiszem, hogy meg kell engednünk magunknak legalább annyi rugalmasságot, amennyi az ember minimális szabadság-szükségletét kielégíti. Az ügyfél túl fogja élni, az agilis értékrend pedig elvárja.
