Csapatmorál az agilitásban

Az előző bejegyzésben elemzett mondat folytatódik; a teljes mondat így hangzik: “If you carry this way of working on for months or years, you get a lot of technical debt and you get low morale” – “Ha hónapokon, vagy éveken át így dolgozol, rengeteg technikai adósságot halmozol fel es alacsony lesz a morál”.

Azért különösen érdekes az állítás második fele, mert az agilis módszertanok mellett elég gyakran megjelenő érv, hogy javítja a morált. Egy esettanulmányban 30%-os fizetésemeléssel egyenrangú mértékű javulásról számolnak be: “Besides being extremely beneficial, working using Agile practices has boosted our company’s team morale much better than if I were to give employees a 30% raise”. (IBM, ThoughtWorks, Forrester)

Mik azok a faktorok, amik az agilitásban különös hangsúlyt kapnak és jó hatással vannak a morálra? Mindegyik kétélű fegyver; ha nem, vagy nem úgy használjuk őket, ahogy módszertanilag ki vannak találva, visszaüthetnek…

• Ügyfélközpontúság, ügyfélközeliség és ügyfél-feedback
Három erősen összekapcsolódó dolog, amiket ha sikerül megvalósítani, a rövid iterációs hossz miatt a folyamatos siker érzését adják, valamint azt az élményt, hogy a termékünket valóban használják és egyre jobban szeretik.
Egy tradícionális modellnél csak ritkán, nagyon hosszú időközönként érhető el a siker és a hasznosság érzése, sőt, rossz esetben, ha nagyon félrement a fejlesztés a fentiek hiánya miatt, akkor soha.
Amennyiben azonban az ügyfél nem létezik (elefántcsonttoronyban megálmodott terméken dolgozunk, ami egyáltalán nem biztos, hogy bárkinek is kell), távol tartjuk a fejlesztéstől vagy csak szimuláljuk, tehát valódi piaci tapasztalat és visszajelzés nélkül halad a fejlesztés, a termék kiadása után ugyanúgy előfordulhat, hogy kiderül: feleslegesen dolgoztunk. Mivel azonban az agilisról szóló reklámanyagok mást ígérnek, ez esetben sokkal nagyobb lesz a csalódás.

• Közös gondolkodás
Az agilitás által definiált üzlet-fejlesztés együttműködés fő jellemzője. Az üzlet rendszerkövetelmények helyett felhasználói problémákat és üzleti célokat hoz, amelyek megoldására a fejlesztőcsapattal közösen gondolkodva találják meg az utakat (üzletileg) és amelyek technikai megoldását a csapat saját hatáskörben, önállóan találja ki. Ily módon a csapattagok sokkal inkább be vannak vonva a termékfejlesztésbe, és nagyobb teret kap egyéni szakértelmük, kreativitásuk is.

• Minőség
Mind technikai, mind funkcionális szinten erősödik a minőség azáltal, hogy a tesztelést a fejlesztés részévé tesszük, kimondjuk, hogy a technikai kiválóságra folyamatosan figyelni kell és Scrum esetén a Definition of Done-nal beállítjuk mindkét minőségi szintet. Jó minőségű terméket szállítani nagyobb büszkeség, szívesebben mesélünk róla a barátainknak is.

• Folyamatfejlesztés
A retrospektívek valódi jelentése, hogy ezen módszertanok esetén nem a vezetőség, rosszabb esetben egy külső szakértő határozza meg és kényszeríti a csapatra a követendő folyamatokat, hanem egy közös kezdeti megegyezés után a csapat hatalmat kap a saját folyamatai fölött (bizonyos korlátok között, természetesen) és lehetősége lesz azt rendszeresen fejleszteni, javítani.

• Csapatmunka
Egy kreatív, egymást segítő, a közös cél felé együtt haladó csapatban dolgozni nagyon jó érzés, emberileg és szakmailag is. Idő, amíg egy friss csapat ilyenné tud válni, ezért is nagyon fontos a csapat stabilitásának megőrzése.

• Scrum értékek
A fenti pontokban implicit megjelennek, de fontos külön is kiemelni: a Scrum által definiált öt érték sikeres megteremtése szintén nagy, pozitív hatással van a morálra. Az öt érték pedig: nyíltság (openness), fókusz (focus), tisztelet (respect), bátorság (courage) és elkötelezettség (commitment).