Szakma-és önkritikus szösszenet a termékké avanzsált agilis szervezetfejlesztésről és oktatásról, egy kis történelmi és szervezetkulturális kitekintéssel.
Olvasási idő: 15-20 perc
Egy adag morális és szakmai értékrendet kérnék, előre utalok
A szakmán kívülállóktól gyakran megkapjuk, hogy az IT-piac az egyik legkíválóbb példa az elitizmusra, hiszen a féktelen ütemben megjelenő innovációk és az azokat kiszolgáló szakmai tudásanyagok eredendően képtelenek naprakészen maradni, ezáltal a piac „genetikailag” hajlamos elveszíteni a józaneszét: ha aznap nem fedez fel új dolgot, akkor másnap létező szakirodalmakat fogalmaz át és ad el újra, újabb és újabb redundáns rövidítésekkel gazdagodunk („Shiny object syndrome„), és sikertelenségnek éljük meg, ha nincs meg a mindennapi innováció. Ezáltal az IT-szakértelem ritkasága és exkluzívvá válása miatt annak keresleti görbéje a végtelenbe nyúlik, a szolgáltatási szektornak pedig ma már egy összetett rétege dolgozik kizárólag azon, hogy az IT profilú cégek hatékonyságnöveléséhez járuljanak hozzá. Az IT-ra specializálódott recruiter-cégektől kezdve az utánpótlásnevelésen át egészen a megbízásos alapú szervezetfejlesztésig juthatunk.
Persze joggal kérdezhetnénk magunktól, hogy „Rendben, de melyik sikeres piac nem válik elitistává?”, hiszen valamilyen szinten természetesen mindegyik lehet az, és közgazdaságtani törvényszerűségéből fakadóan akár közhelynek is tekinthető ez a fogalom.
Egy dologban azonban az elitizmusra épülő modern szervezetfejlesztés (de hívhatjuk piaci hatékonyságnövelésnek is) jelentősen eltér a történelem múltbéli üzleti filozófiáitól, ezért sokkal több, mint közhely. A kulturális kommunikációelmélet és az emberi lélektan múlt évszázadi fejlődése vezetett oda, hogy a 2000-es ezreforduló táján megjelenhettek az első olyan igazi és hasznos tanulmányok, melyek a vállalati működéssel közös kontextusba helyezték a kultúra és psziché fogalmait. (ajánlott szakmai irodalom: Róka Jolán, Sandra Hochel: Interkulturális és nemzetközi kommunikáció a globalizáció világában, 159. oldaltól)
Habár az emberiség addig csak kapizsgálta, nem kellett sok hozzá, hogy egy szempillantásra a lelki jólét váljon az individualista (nyugati és európai) szervezeti kultúrák központi alkotóelemévé.
Az előző bekezdésekben említett jelenségek pedig nem maradtak következmény nélkül. Az elmúlt húsz évben ugyanis a két legjelentősebb gazdasági és kulturális erő – a tágabb értelembett vett informatika és az egyénközpontú szervezeti politika egyesült, akár egy kétkomponensű szuperragasztó. Beépült a szolgáltatásszektorba a szervezeti tanácsadás, majd a szervezetfejlesztés részeként az IT piac legkomolyabb tudományává nőtték ki magukat a szoftverfejlesztés-specifikus módszertanok, keretrendszerek, ajánlások, kulturális javaslatok,
és ezek értékesítése.
A szervezetfejlesztők és módszertani iskolák, projektmenedzsment gyorstalpalók ma már szinte termékként közvetítik az Agile alapú tanokat. Onnantól kezdve pedig, hogy ezt a tudást már nem kizárólag az iskoláinkból és első mentorainktól kapjuk, hanem cégünk szolgáltatásként igényelheti számunkra azt, onnantól akaratlanul ugyanazzá válik a tudásunk, melynek értékesítésére azt használnánk: Termékké. Ez az üzletgazdaság egyik még legrejtettebb paradoxona. Egy olyan ellentmondás, amelyből kizárólag a szakmai éleslátásunk józaníthat ki.
A termékként megrendelt, ezáltal elsietett szervezetfejlesztés olyan, mint a lassan ölő, gyógyír nélküli drog. Jellemző a mértéktelen fogyasztása és túladagolása. Még ha létezik is rá orvosság, az maga is vállalatspecifikus gyógyírt jelent, és mint a függő beteg, aki halálát sejtvén kétségbeesetten rohan az elvonóra utolsó leheletével, úgy fut versenyt a cég is az idővel a megoldásért, csak hogy neki eközben pénzt is kell termelnie, és az alkalmazottai mellett az orvosságot is ki kell fizetnie valamiből. De az elsietett szervezetfejlesztést lehetetlen veszteség nélkül utókezelni.
Ha elég bonyolultan magyarázom, inkább rámbízod
Nem napjaink szoftverfejlesztési-projektmenedzsment módszertanaival van probléma, hiszen a szándékuk és kulturális (pl. Agile) eredetük okán a modern vállalati élet legdicsőbb és legőszintébb találmányainak tartom őket.
A probléma inkább ott kezdődik, hogy üzleti érdeknek számít az, hogy minél később szembesüljünk a ténnyel: Egy szinte minden fogalomra kitérő 400 oldalas Scrum tankönyv ősforrása nem más, mint a jelenleg 13 oldalas Scrum Guide. Továbbá arról is sokan megfeledkeznek, hogy egy magolással tanulható módszertan és egy keretrendszer (Scrum) között szakadéknyi különbség van.
(A továbbiakban többször is a módszertan szót használom majd – de függetlenül a néha témában felmerülő Scrum-tól – azért teszem, hogy elkerüljem a szoftver-keretrendszer szóval való összecsengést.)
Tehát visszatérve: 13 rövid oldalacskáról beszélünk, és a Scrum folyamat megalkotói sem gondoltak többet bele, mint ami. (egy kis érdekesség: az ominózus, egyik legnépszerűbb, kb. 400 oldalas angol nyelvű Scrum tankönyv még részben sem idézi vagy hivatkozza a szakma két bibliáját, az Agile Manifesto-t és a Scrum Guide-ot, kizárólag csak feldolgozza azokat. Ellenben míg a könyv méregdrága kurzusok oktatási eszköze lehet, addig a teljes szakma bölcsességének forrása ingyen elsajátítható az előbbi két linken, kb. 30 perces olvasást követően.)
A Scrum egy jó dolog. De nem rakétatudomány.
… Hiába épül egy komplett szolgáltatási szektor arra, hogy elhitesse annak tényét, hogy kizárólag többszáz oldalnyi tudásanyag elsajátítása után lehet belőled Scrum Master vagy Product Owner. És valljuk be, milyen könnyű is elhinni ezt, ha a végén egy certification-nel is kecsegtetnek. De még ezzel sincsen baj, hiszen ha releváns szakmai tapasztalat nélkül szeretnél belépni erre a piacra, valamivel igazolni kell a lexikális tudásodat, azt pedig – nincs mese – csak a 400 oldalas magolás által kiváltható papírral teheted meg, akárcsak egy egyetemen.
A száraz tankönyvek és költséges gyorskurzusok azonban abban különböznek egy valódi mentortól, hogy utóbbi nem felejt emlékeztetni az oktatás és a tanulásmódszertan talán legfontosabb szabályára:
A vastag könyvek csak lexikális tudást adnak, a hiányzó bölcsességet pótolják tényekkel. De a vastag könyvből a nap végén semmit sem profitálsz, ha nem értetted meg a téma esszenciáját – a téma „ősi bölcsességét”.
A köz-és felsőoktatás hivatásos és végzett oktatóinak általában küldetése, hogy megértessék a fenti sorokat a diákkal. Viszont a „módszertan-kereskedő” szervezetfejlesztő vállalkozásoknak nem célja ugyanez (akik kivételek, ők a szakma igazi kincsei), hiszen a valódi igaz oktatás magában hordoz egy anyagi veszélyt: ha az ügyfél túl sok igaz bölcsességet kap és esetleg túl hamar jön rá magától az egész módszertan nyitjára, akkor esetleg elérheti a célját a költséges lexikális tudásanyagok nélkül is.
Habár az átlagember nem teljesen védtelen ezzel a jelenséggel szemben.
- Amikor megunjuk a biztosítónk túlbonyolított leveleit – és inkább felhívjuk a kapcsolattartónkat,
- vagy elegünk lesz egy érthetetlenül „túlmarketingelt” álláshirdetésből – és inkább bezárjuk azt,
- vagy esetleg felmegy a pumpa, amikor egy televíziós közszereplő bonyolult körmondatokkal válaszol egy egyszerű riporteri kérdésre – és rákiabálunk a TV-re, hogy „Válaszolj már arra, amit kérdezett!”
… ez mind ugyanaz a problémakör, mint a túltolt tudáskereskedelem a szoftverfejlesztési módszertanok világában.
Az igazi megoldást azok a módszertani iskolák, coach-ok és mentorok jelenthetik, akik a diákjaikat, ügyfeleiket vagy beosztottjaikat valódi és elhivatott tanárként oktatják, akik tudás mellett tanulni is tanítanak, vagyis azok, akik a hivatásukra
rászánják az időt.
Akik ebben nevelkednek, azok számára nem létezik más
Mivel a precíziós és agilis szervezetfejlesztés és coaching nem első sorban vállalati léptékben, hanem egyéni-személyes szinten kezdi meg a tevékenységét, ezért a feladatköre nem csak üzleti szintre, hanem az emberi oldalra is kiterjed, ezáltal hatalmas, ténylegesen nehezen felfogható felelősséget vállal. Az Agile-alapú tanok elvárják a cégtől és az embertől is a rugalmasságot, a dinamizmust, tehát olyan emberi „alapanyagok” számára hirdeti magát, akiknek természetes és őszinte tulajdonságuk a változásra való hajlandóság. Ez pedig pontosan ugyanaz az alapfeltétel, mint amit egy diáktól vagy hallgatótól várnak el az iskolában,
azaz kijelenthetjük, hogy az agilis coaching szerepet vállal a jövő elméinek és fiataljainak szakmai és emberi tanításában is. De felelősséget is vállal?
A költői kérdésre a válasz: felelősséget kell vállalnia. Az már más kérdés, hogy a coaching szellemi tanításait illető felelősségét lehetetlen számon kérni, hiszen senki nem fog megkeresni egy mentort 15 év múlva, hogy a szemébe mondja: „Tök fals képem alakult ki az üzleti világ működéséről, fizesd vissza a pénzemet”, mert ilyen nem létezik. Az egyetlen kapaszkodónk, ami marad, az a morális erkölcsön nyugvó szakma szeretete, amit csak másodikként követhet az anyagi érdek (amely természetesen ugyanúgy kiemelt fontosságú).
Utóbbi szemléletmóddal bíró szakemberek vannak kisebbségben.
Az, ahogyan a „termékként” sulykolható agilis szervezetfejlesztés és az „eladások” általi módszertan-túladagolás politikája az IT-utánpótlás-neveléshez viszonyul, annak döntő szerepe van az oktatottak jövőbeli karrierútjában és szakmai viselkedésében. Akik a közoktatásból frissen érkeznek a szakmába és első munkahelyeik között tapasztalják meg az Agile világát, azok számára az lesz a mindenség, az lesz az univerzum, a módszertanok által kialakult tudásuk határozza meg a viselkedésüket és az üzleti világról alkotott képüket, hiszen abban nevelkednek. Ezt a világról alkotott képet pedig nem mindegy, hogy pontosan milyen motivációktól hajtott Agile-szakember alakítja bennük – egy olyan szakember, aki gondolkodni és tanulni tanítja meg őket, vagy egy olyan, aki kizárólag csak egy könyvet nyom le a torkukon.
Oké, de mitől lesz a módszertan túladagolt?
Attól, hogy aki kizárólag profitcentrikusan, termékként eladja a tudást, az szándékosan adagolja túl a lexikális maszlagot háttérbölcsesség nélkül, aki pedig kapja a tudást, az onnantól kezdve ilyen minőségében adja majd tovább, és így örökölhető a jövőben a felületesség, „lufi”-hozzáértés és a kollégák kiégetésének művészete, akárcsak egy családi trauma, ami szintén képes generációkon át vándorolni, és lassú folyamatként orvosolható.
A következmény pedig az, hogy a felületes agilis gondolkodók képtelenek lesznek az egyik legfontosabb alapelv betartására, a valódi változás iránti készségre, ezáltal sosem vagy csak nehezen látnak ki az Agile-burokból. Az ő világukban a legsúlyosabb szervezeti és egyéni problémákra is kizárólag az erőforrásterheltség és a számok a válasz, esetleg megpróbálkoznak egy másfajta iteráció-ütemezéssel, de a „betegségük” legelőrehaladottabb állapotában már olyan mondat is elhagyhatja foguk kerítését egy személyes jellegű segítségkérésnél, hogy „Nem projekttéma, úgyhogy a következő retrospektíven, amikor erre időnk van, felveszünk rá egy action-point-ot.”, miközben a probléma egy kávézás közben is megoldható lenne.
(A problémakör önmagában komoly és aktuális téma, ebben a cikkben írok róla részletesebben)
Ez nem más, mint maga a módszertan-túladagolás. Amikor olyan mennyiségben zúdítják ránk és zúdítjuk mi magunkra egy adott iskola szabályait, hogy elfelejtjük, milyen maga a módszertan nélkül is élni. És a saját józanságunk azért kiemelten fontos, mert a modern módszertanok nem rossz szándékból, de eredetüktől fogva félreérthetők lehetnek, hiszen azt mondják, hogy csak önmaguk értelmezési tartományában működőképesek. Ezáltal hamisan abban a tudatban élhetünk, hogy ha a módszerrel probléma adódik, nincs baj, hiszen biztosan mellékelt magához gyógyszert is. És egy burokban élő Scrum-team tag felteheti neked a kérdést, hogy miért is kellene neked Scrum nélkül élni, hiszen ha problémád van, arra is van megoldása: nem elég jó a retrospektív? Na, mit mond akkor, ha neked nem jó? Semmit. Ugyanis az „igaz” Scrum sosem jelentette ki magáról, hogy nem élhetsz néha nélküle is, és nem kereshetsz máshol segítséget. Sosem írta le, hogy kötelező túltolnod.
Súlyos diagnózisnak számít, ha azon kapja magát egy kolléga, hogy nem tud rendszerfüggetlenül gondolkodni és működni? Igen. Segítségre van szüksége, gyógyítóra, egy igazi mentorra, aki kirántja a burokból.
Az Ember és megfigyelése, majd visszatérése a természetbe. Narrálja: David Attenborough
Mivel üzleti felelősségről beszélünk, ezért egy emberi közösség menedzselése (és pl. egy agilis transzformáció) során az egyik legnagyobb kihívás felismerni azt a bizonyos sorsdöntő csúcspontot, amikor már nem mehetünk vissza a szervezetfejlesztés azon útján, amelyen addig haladtunk, és két választásunk marad: üzletileg kedvező jelek esetén továbbhaladni – és véglegesen nyomot hagyni a cégen, végzetes jelek esetén pedig elővenni a tökeinket, és feltenni magunknak a kérdést:
Mi jár a legkisebb veszteséggel? Mindent újrakezdeni, vagy afféle „re-engineering” módon lassan visszabontani egy szintig a folyamatunkat?
Ez így önmagában nem is különösebb blogtéma, hiszen a képlet adott és mindenkinek fekete-fehér: kicsi problémák esetén visszabontjuk azokat és gyógyítjuk a folyamatunkat, teljes káosz esetén pedig dobunk mindent a szemetesbe. Pont. De akkor mi is itt az igazi kihívás?
Hát az, hogy legyen vér a pucánkban felismerni azt a bizonyos ominózus, gyógyíthatatlan káoszt, amikor illik újra elölről próbálkozni.
És ezt tartom az igazi agilis gondolkodásmód egyik legértékesebb és legnehezebben elsajátítható tulajdonságának. Ha ez megvan, akkor mondhatjuk el, hogy ténylegesen értjük az értékrendszer „think-outside-the-box” jellegét. Nyilvánvalóan nem egyszerű, hiszen az ehhez vezető első lépcsőfok az egyéni és szervezeti szintű önkritikus gondolkodás, a hibák beismerése, az ego teljes kizárása. Kevesen tudják azt mondani, hogy srácok: „Próbálkoztunk egy évet vele, de ismerjük be, a 30-ból volt 8 sikeres sprintünk, nem megy nekünk ez a Scrum, egyszerűen a személyiségeink nem passzolnak hozzá, rosszul érzitek magatokat, és amúgy az ügyfél sem annyira nyitott. Próbáljunk ki egy másik eszközt.” Miért ne létezne ilyen? Nem bűn, nem kudarc, és ezt a hierarchia legtetejének is meg kell értenie. A sportcsapatok sem egyről a kettőre találják meg a nekik való taktikai felállást.
A lehető legrosszabb reakció, amit ilyen szélsőséges esetben vezetőként vagy coach-ként tehetünk, hogy elkezdünk kis lépésekkel araszolni, próbálni forgatni a szervezetfejlesztés Rubik-kockáját „még egy kicsit”, és csak telnek és telnek a hónapok, játszadozunk a kockával, és mire eszmélünk, hopp, elfogyott a csapatunk.
(Természetesen ki kell térnünk arra is, hogy van az „újrakezdés politikájának” egy nagyon trükkös tulajdonsága. Ezt a stratégiát a legkönnyebb választani. Ezáltal elsőre nehezen megkülönböztethető, hogy az újrakezdés döntése a döntéshozó amatőrizmusából vagy éppen teljes profizmusából eredeztethető-e. Hiszen az amatőr éppen azért választja az újrakezdést, mert sokkal könnyebben átlátható projekt egy új házat építeni, mintsem lebontani azt csak egy bizonyos tégláig. A hozzáértő pedig a teljes ellentéte, aki azért építi újra a házat, mert statikai szakismerete ezt indokolta. Hogy a megbízó vagy cégvezető vállalja-e ennek a kettőségnek a kockázatát, amikor agile szakembert alkalmaz, akkor nincs mese, egyedül a saját szakma és emberismeretében bízhat.)
No de térjünk vissza az újrakezdés valódi, nem kamu „művészetére”. Hogyan a leghatásosabb csinálni? Hogyan csináljuk minimális veszteségekkel, sőt, egyből stratégiai előrelépéssel?
Kezdésképpen úgy, hogy emlékeztetjük magunkat arra, hogy minden vállalat legkisebb alkotóeleme az egyén, tehát agile szakemberként a kommunikációs tanok és a szociálpszichológia legalapvetőbb szabályait kell előkapnunk a farzsebünkből. Kiváltképp a csoportdinamikára vonatkozóakat. Ha pedig ilyen szemüvegen keresztül szeretnénk megvizsgálni a csapatunkat, akkor második feladatunk, hogy megteremtsük a megfigyelési folyamatunkhoz tartozó előfeltételt, ami nem más, minthogy kirántsuk az embereket a kudarcot vallott módszertani keretek közül, és átmenetileg bevezessük a kontrollált káoszt. Vagyis harmadik lépésként vennünk kell a bátorságot, hogy azt mondjuk a csapatnak: mostantól két hétig nincsenek szabályok. Nincs napi státusz, nincs demózás. Kiürítjük a teljes szabályrendszerünket, mint akár a böngészőnk cache-ét, és egyedül a munkaidőt, a projektcélt és a szállítási határidőt tartjuk meg. És ha valakinek nehezen megy át a szándékunk, brutálisan csak annyit szabad válaszolnunk a „hogyan” kérdésekre, hogy „nem mondom meg, találd fel magad, de az eredményt szállítani kell”. És innentől kezdve a negyedik feladatunk már csak annyi, hogy visszavigyorgunk a ledöbbent arcokra, leülünk, majd folyamatos megfigyelési üzemmódba kapcsolunk, ugyanis
magától fog beindulni a csoportdinamika öngyógyító mechanizmusa,
a csapattagok sokkal ösztönösebben és önállóbban fogják megkeresni a projektcélhoz vezető utat, kénytelenek lesznek maguk megoldást találni a működési problémáikra, maguk megteremteni egy kommunikációs csatornát egy másik emberhez, saját meeting-szervezésre kényszerülnek. Az önállósági és szakmai tapasztalati szinteknek megfelelően kialakulnak a puha hierarchiai és íratlan csoportszabályok, és mire kettőt pislogunk, azt láthatjuk, hogy a megfigyelt csapat természetes módon, saját személyes viselkedésük és hatékonyságuknak megfelelő mintázatokat alakított ki.
Ezzel sikeresen kinyertük a csapatunk működési „DNS”-ét.
Utolsó teendőként pedig elkezdhetjük magát a módszertani újraformálást, ám ezúttal ez a „DNS” a csoportdinamika legértékesebb kincseként már a kezünkben van. Ezzel átadhatjuk a stafétát a lexikális tudásunknak, hiszen rendkívül fontos lépés lesz kiválasztani a csapatunk ösztönös működéséhez legközelebb eső projektmódszertant, vagy ha nem létezik optimális és előre kidolgozott keretszisztéma, akkor eljött az idő arra, hogy egy egyedi és cégspecifikus folyamatfejlesztést kezdjünk el, akár létező keretek kombinálásával.
(Nyilvánvalóan a fenti eljáráspélda egy ideális világot tükröz, nem veszi számításba a zavaró tényezőket, például: mi van azzal a nagyon-nagyon ritka esettel, ha a kontrollált káosz módszere sem működik? Mi van akkor, ha elszabadulnak a kollégák, a kontrollált káoszból kontrollálatlan lesz, majd az irodánkból egy 0-8-as kocsma lesz? Természetesen ez annak a jele, hogy a csapatunknak egész konkrétan nem hogy gyenge, semmilyen üzleti érdekű csoportdinamikája sincs, nincsenek benne sem szakmai, sem szellemi vezetők, csupán „gyerekek” hada. Ha tehát azt látjuk, hogy a csapatunk a DNS-e alapján „ősi” szinten képtelen egy közös üzleti cél elérésére, akkor két választási lehetőségünk van: új csapatfelállás kialakítása, vagy egy emberi értékeket kevésbé értékelő, annál katonaibb jellegű szabályrendszer felállítása.)
És habár a tapasztalt szervezetfejlesztők vagy tehetséges vezetők számára az egyedi csapatműködés elősegítése, másnéven a klasszikus folyamatfejlesztés egy ismert és évtizedek óta alkalmazott „józan paraszti” eljárásrend, mégis az elmúlt években a szigorú keret-és módszertanfüggőség dominál, mint egyfajta „megszaladt” evolúciós lépcsőfok.
Módszertan „brand” helyett józan paraszti folyamatfejlesztés. Ez a jövő?
A cikk legfontosabb kulcsszava a józanész, és a fentebb leírtaknak megfelelően úgy gondolom, hogy a józaneszünk mércéje végül abban fog megnyilvánulni, hogy a jövőben milyen gyakran leszünk képesek választani a két lehetséges szervezetfejlesztési „üzletpolitika” közül: az előző fejezetemben többször is említettem a klasszikus, egyedi folyamatfejlesztés fogalmát, ellentétként felállítva a szigorú, sablon-szabályrendszerekkel szemben.
Ugyanúgy ahogy a természet és minden más faj alaptulajdonsága, úgy az emberé is az, hogy előfordulhatnak benne evolúciós megszaladások (jelentése: kontraproduktív túlfejlődés, túlműködés). A megszaladások pedig a szoftverfejlesztés világán belüli agilis működési rendekre is jellemzők, sőt, úgy hiszem, hogy ennek a virágzását éljük éppen. Hiszen ahogy a tudomány is fejlődik, azaz egyre több absztraktabb, nem nevén nevezhető ismerethalmaz válik azonosított jelenséggé, ahogy egyre több lelki probléma kap feleslegesen új orvosi rövidítéseket betegség címen, úgy a módszertan-fejlesztés tudománya is egyre több „márkanevet”, rövidítést és szépen fénylő megnevezést bocsát ki magából. Ennek meg is van egyelőre az eredménye: ha azt mondod, hogy a csapatod dinamikusan, rövid határidőkkel, gyors ügyfél-visszaellenőrzésekkel működik, kevésbé tűnsz trendinek, kivéve akkor, ha szótári megfelelőjét, pl. a Scrum nevet használod inkább.
Az ember természetes jelleméhez tartozik, hogy kíváncsi, kísérletezik, feszegeti a határokat, így persze senki sem „bűnös”. Szintén kísérletezgetésnek bizonyul, amikor olyan projektrendszereket dolgoz ki, amelyek szabályai felrúghatatlanok, és arra tanítanak, hogyha nem engedelmeskedsz nekik, kudarcot fogsz vallani. A módszertan-túladagolás kora tehát nem azt jelenti, hogy kollektíve rossz irányba haladunk vagy talán világszintű bűnbakért kellene kiáltani, hanem azt, hogy a szakmai felfedezésünk útján elmentünk addig a pontig, amíkor már a kialakított szabályrendszereink béklyóvá válhatnak. Vagyis messze vannak az emberi lény alaptulajdonságaitól, és sokkal inkább hasonlítanak a módszertanaink afféle törvénykönyvekre, és nem szolgálják már teljesen azt a célt, amit az Agile Manifesto anno megfogalmazott.
A szoftverfejlesztési módszertan-sablonok evolúciós elődje tehát a klasszikus folyamatfejlesztés, üzleti hatékonyság-fejlesztés, ami egy csöppet sem új találmány. Szervezetfejlesztők, HR-esek, IT-infrastruktúra-fejlesztők, Business Analyst-ek, Product Owner-ek, Konzulensek alaptudásáról beszélünk, egy olyan alapbölcseség-készletről, amely
folyamatot felmér, elemez, újat rajzol vagy átrajzol, tesztel, optimalizál, majd bevezet,
ahelyett, hogy
tankönyvet nyom a kezünkbe,
és amelytől régóta függ komplett cégek működése. Nyilvánvaló persze, hogy ezt a szakmai tudást nehéz közvetíteni a villámkurzusok piacán, hiszen a brand nevekre és kulcsszavakra épülő marketing szakmának nehéz olyas valamit felkarolnia, amelyről kizárólag csak annyit tudna mondani, hogy: „Szakmai rutin kell hozzá.” Mert valóban, a folyamatfejlesztés szaktudást és rutint igényel, és a leghatékonyabban oktatni csak olyan hallgatókat lehet, akik valamilyen szakmai előélettel rendelkeznek. Nem véletlenül protokolláris elvárása a szervezetfejlesztői vagy IT vezetői egyetemi Msc / MBA kurzusoknak a releváns előképzettség vagy egy önélatrajz által bizonyítható szakmai tapasztalat.
Ahogyan minden biológiai, tudományos, gazdasági vagy kulturális megszaladásnak természetes következménye, hogy hosszabb vagy rövidebb idő után, de biztosan visszatalál a nyugalmi állapotába, úgy biztos vagyok benne, hogy a szoftverfejlesztés szervezeti folyamataira is ez a jövő vár. Legalábbis őszintén remélem – még akkor is, ha az út legelején járunk még. Ugyanis tudatosítanunk kell magunkban, hogy az Agile alapelvei nem csupán arra jöttek létre, hogy X év elteltével a tökéletességig kifejlett, törvénykönyként funkcionáló módszertanokat fejlesszenek ki belőlük, hanem hogy a manifesto-pontok egészen 2001-től a mai napjainkig, és még további évtizedekig is minket, embereket és gondolkodásmódunkat fejlessze. Meg kell hallanunk, ahogy az Agile afféle szellem-Obi-wan-ként a fülünkbe suttogja: „Hát még mindig nem érted?”, és engednünk kell, hogy átjárjon minket az „erő”. Az Agile abszolút célja ugyanis az, hogy a szakmai társadalmunk elérje azt a kort, amikortól olyan természetessé válnak az értékei, hogy már nevén sem kell neveznünk azt. És az lesz az a pont, amikor az „evolúciós megszaladás” visszatalál a nyugalmi állapotába, amikor magától értetődő lesz, hogy a helyes fejlesztői csapatok működéséhez valódi folyamatfejlesztő szaktudásra lesz szükség (és talán addigra már sokkal több szakemberünk lesz), és persze lesz még egy hatalmas előnyünk: birtokunkban lesz mindazon bölcs és hatalmas nagy munkával formába öntött lexikális tudáshalmaz, amit az akkori múltban (most jelenben) tucatszámra eladott módszertani tankönyvek hagytak örökségül, ám akkor már nem törvénykönyvként, hanem úgymond „néha a megfelelő helyen kinyitandó bibliaként” fogjuk őket használni.
