Cargo cult SCRUM

Korábban írtunk már az agilis módszertanok körüli tévhitekről, melyek közül talán a legnépszerűbb az a vélekedés, hogy bevezetésükkel minden probléma magától megoldódik, a fejlesztések felgyorsulnak, az emberek pedig motiváltak, és boldogok lesznek. Egy szóval, hogy minden ami agilis, az egy svájci bicska is egyben. Mivel a SCRUM a legelterjedtebb metodológia, ezért most ezen keresztül mutatjuk be az agilis módszertanok ész nélküli alkalmazásának útvesztőit, de természetesen tetszőlegesen alkalmazható az analógia akár a Kanbanra, vagy a Leanre is.

Míg néhány helyről azt hallani, hogy a SCRUM tényleg mindenre gyógyírt jelentett, a bevétel nőtt, a túlórázások megcsappantak, sőt még a céges fifázások színvonala is emelkedett, addig legalább ugyanennyi szakember számol be arról, hogy az agilis módszertan bevezetését követően uralkodott csak el igazán a káosz a cégüknél, és ezzel karöltve beköszöntött a frusztráció, és a tanácstalanság a csapattagok életébe.

Cargo cult?

A cargo cult jelenségről is írtunk már. Röviden összefoglalva akkor beszélhetünk erről, ha téves összefüggést feltételezünk ok és okozat között, és aztán ezekre a nem létező okokra építünk fel valamit, várva az eredményt.

A cargo cult SCRUM

Újabban, ha egy cégnél nem működnek jól a belső folyamatok, esetleg a fejlesztések lassan, vagy rossz minőségben készülnek el, akkor előbb, vagy utóbb megszületik valakinek a fejében, hogy ide bizony SCRUM kell, azzal majd minden megoldódik! Itt kezdődnek a problémák. Anélkül próbálnak ugyanis megoldást találni a gondokra, hogy tisztában lennének azok okaival.
Ez a felületesség aztán megmutatkozik az új metodológia bevezetésekor is, figyelmen kívül hagyva, hogy a SCRUM csupán egy implementációja az agilis módszertannak, erősen építve annak alapelveire. Ha úgy tetszik, akkor egyetlen agilis módszertan sem más, csupán egy eszközkészlet ezeknek az elveknek a gyakorlati alkalmazásához. Vagyis, ha valaki megérti, és szem előtt tartja az alapelveket, akkor képes az ész nélküli másolás helyett definiálni egy adott szervezetre szabott módszertant, csak sajnos idáig kevesen jutnak el.

Két gyakori tévút

A leggyakoribb hiba a SCRUM bevezetésekor a tökéletes klónozásra tett kísérletre vezethető vissza. Valaki, valahol olvas egy cikket a SCRUM-ról, aztán betűről-betűre mindent ráerőltet belőle a saját szervezetére, abban a tévhitben élve, hogy csak így lehet a sikeres az átállás. Lesz a cégnél scrum master, backlog, és persze lesznek daily scrumok, meg sprintek is. Meg lesz káosz is. Ez az eljárás ugyanis teljesen figyelmen kívül hagyja, hogy különböző csapatoknak, különböző körülményekre és folyamatokra van szükségük, mely nagyban függ a csapattagok személyiségétől, és az elvégzendő munka jellegétől is. Ezzel pedig tulajdonképpen rögtön ellent is mond az agilis kiáltvány legelső pontjának, mely szerint: "(value) individuals and interactions over processes and tools".

A másik gyakori hiba, amikor a szervezetben létező problémák nem pontosan ismertek, és ugyanígy egzakt célt sem tűznek ki a SCRUM bevezetésével egydidejűleg, csak remélik, hogy ezzel minden problémát visszamenőlegesen, és a jövőre nézve egyaránt letudnak. Aztán persze kis idő múltán egyre többeknek feltűnik, hogy nem is változott semmi, csak más nevet adtak az eddigi módszereiknek.

Mit lehet tenni?

Ha mégis úgy gondoljuk, hogy bevezetünk egy agilis módszertant, akkor az első, és legfontosabb, hogy legyen egy tényleges csapatunk, akivel ezt megtehetjük. Itt fontos megjegyezni, hogy random emberek, random csoportja nem fog csapatot alkotni attól, hogy annak hívjuk őket. Kell hozzá egy közös cél, és kellenek egymással jól "működő" csapattagok is.
A továbbiak:

• Értsük meg az agilis kiáltványt, és főleg annak alapelveit, próbáljuk meg lefordítani őket a saját szervezetünkre vetítve.
• Kezdjük kicsiben, és főleg egyszerűen. Ne használjunk olyan eszközöket, és gyakorlatokat, amikre nincs szükségünk.
• Folyamatosan figyeljük a változásokat, és ezek alapján finomítsunk a gyakorlatokon, módszereken, folyamatokon.