Nem mindegy, hogyan skálázod az agilitást

A szoftverfejlesztő csapatok körében már bizonyí­tott tény, hogy az agilis keretrendszerek implementálása – mint a scrum vagy a kanban – segí­t gyorsabban az ügyfelekhez juttatni az új megoldásokat, emellett sokkal kiszámí­thatóbbá teszi a folyamatokat és új információ esetén a rendszer rugalmasan képes reagálni – mondja többek köztött a világ legtöbb agilis csapatát szoftver eszközökkel kiszolgáló vállalata az Atlassian. A kihí­vás azonban: hogyan lehet ezt a hatékonyságot csapat szintről az egész vállalatra kiterjeszteni? Egy szóval: hogyan skálázódik az agilitás?

A Saab repülőgépgyártó részlegén jelenleg több mint száz agilis csoport dolgozik a Gripen vadászrepülőgép szoftverén, hardverén és törzsén, egy háromszázmillió dolláros terméken, amely nemcsak kinézetében, hanem összetettségében is robosztus. Egy ilyen masszí­v projekt esetében az ember azt gondolná, hogy rengeteg erőforrásra van szükség a számtalan különleges szakterületeken dolgozó csoport koordinálásához és a felmerülő problémák megoldásához. A Saab azonban elérte, hogy a JAS 39 Gripen a világ legnagyobb költséghatékonyságú vadászgépévé váljon. 

 SAFe morning everybody! 

Az agilitás skálázása (például a SAFe keretrendszerben – Scaled Agile Framework) egyszerűen definiálható: legyen több agilis csoportunk. A kulcs azonban az, hogy miközben emeljük a csapatok számát egyről kettőre, majd tí­zre, százra és í­gy tovább, a vállalatban ki is kell terjesztenünk az agilis gondolkodásmódot. Meg kell találni a módját annak, hogyan használjuk a csapatok csoportjait a nehéz projektek kivitelezésére. Ezt pedig a Saab Aeronautics a Gripen gyártása során tökéletesí­tette. 

A Saabnál reggel 7:30-kor minden frontvonalbeli csapat 15 perces gyűlést tart, hogy kijelölje a problémákat, amelyek egy részét nem lehet a csapaton belül megoldani. Ezután 7:45-kor a komplex nehézségeket átadják a csapatok csoportjának, amelyekben a vezetők egyaránt a problémák megoldásán vagy továbbküldésén dolgoznak. í‰s í­gy tovább, amí­g 8:45-kor a felsővezetésnek is van egy listája a döntő fontosságú problémákról, amelyeket meg kell oldani, hogy a fejlődés ütemét pályán tartsák. Ez egy tiszta kép, amelyet minden vállalatvezető szeretne: minden szakasz megoldja a saját problémáit, vagy az adatok tisztán áramlanak a szervezeten keresztül, amí­g el nem jutnak egy olyan személyhez, aki orvosolni tudja őket. 

Hova tovább? 

Legyenek nagyobb agilis csoportok – ez egyszerűen az agilitás skálázásának egy definí­ciója, amely elsősorban a nagy vállalatok közös tapasztalatain alapul, és sok cégnél működött, ilyen például az Amazon, a Bosch, a Dell, a Facebook, a Google, a Lego, a Microsoft, a Netflix, a Riot Games és még számtalan más vállalat. Azonban nem szabad elfelejteni, hogy miközben az eredmények a fenti példák mindegyikében csodálatosak voltak, az átalakí­tás módja eltérő volt: a megközelí­tés, a hatás vagy akár a definí­ciók tekintetében is. 

A skálázható agilitás lehetővé teszi a csapatok számára, hogy hatékonyan, kiemelkedő sebességgel dolgozzanak.

Agilitás nagyban 

Az agilis vállalat nem a csoportok összehozásának egy módja, hanem a kiegyensúlyozott munkamódszereknek egy olyan formája, amely lehetővé teszi, hogy bármilyen szervezet hatékonyan és kiszámí­thatóan működjön, és egyúttal lehetővé teszi a váratlan lehetőségekben rejlő potenciál kihasználását. Valójában ez az agilis forma olyan szintű, amelyet a hagyományos SAFe-stratégiák már nem is érnek el. Ebben a szakaszban az irányí­tás nem kí­vánja már elkülöní­teni az agilis csoportokat a vállalkozás többi részétől, de nem is próbálja az agilitást minden területre ráerőltetni. 

Egy ilyen vállalat felépí­tése számos pillérre támaszkodik, miközben megvannak az egyedi nehézségei is, mind a felépí­tésében, mind pedig a fenntartásában. Hiába azonban az alapos módszertani tudás és a fegyelmezett emberek, egy komplex szervezetben ezt a fajta működést már nem lehet egy sima excel-táblában menedzselni, ugyanakkor a csapat szintű szoftverek sem képesek átláthatóan, követhetően elvinni mondjuk 100 csapatnyi munkát. A cégek előtt három út van: vagy egy teljesen egyedi szoftvert épí­tenek erre a célra, ami biztosan 100 százalékban megfelel az ő szervezetüknek, igényeiknek, kultúrájuknak, de akkor a továbbfejlesztés, frissí­tés és életben tartás felelőssége is az övék, ez nem egy olcsó mulatság. A második lehetőség, ha egy kész terméket vezetnek be, ami kapcsolódik a csapat szintű szoftvereikhez, mint például a Jira Align – ez sok esetben segí­tség, de előfeltétele, hogy a szervezet folyamatai és tevékenységei a lehető leginkább sztenderdizáltak legyenek, ez nem mindenkire jellemző. A harmadik út pedig, ha a meglévő szoftver platformokon belül készí­tenek egy egyedi plugint, ami a hibrid megoldás a két előzőhöz képest: megadja a dobozos szoftver biztonságát, de kialakí­tható benne az egyedi szoftver rugalmassága.

Bármely verziót is valósí­tja meg egy vállalat, a ShiwaForce tanácsadói azt javasolják minden vállalatnak, ahol az agilitás skálázása terí­tékre került, hogy érdemes egy alapos, teljes szervezetre kiterjedő felméréssel, elemzéssel, tervezéssel kezdeni. Már a licencstruktúra helytelen kiválasztása is évente több millió forintos veszteséget jelenthet, egy nem testreszabott, helytelenül megvalósí­tott skálázott megoldás pedig ennél jóval nagyobb extra költség.