Vajon a skálázott agilitás ugyanolyan mértékben javítja a vállalati teljesítményt, mint az agilis módszerek az egyéni csapat teljesítményét? -merülhet fel sokunkban a kérdés. A 3M, az Amazon, a Bosch, a Dell, a Facebook, a Google, a Haier, az ING, a Lego, a Microsoft, a Netflix, a PayPal, a Royal Bank of Scotland, a Riot Games, a Salesforce, a Spotify és a Target mind növelték az agilis csapataik számát. Bár eredményeik általában lenyűgözőek, a vállalatok megközelítései, eredményei és még a skálázott agilitás definíciói közötti különbségek is szembetűnőek.
A Saab repüléstechnikai üzletágában több mint száz agilis csapat dolgozik szoftvereken, hardvereken és repülőgép felépítményeken a Gripen vadászrepülőgéphez. A Gripen egy 43 millió dolláros termék, amely ijesztő összetettségét tekintve. Reggel 7:30-kor minden csapat tizenöt perces megbeszélést tart, hogy megjelölje azokat az akadályokat, amelyeket az adott csapaton belül nem lehet megoldani. 7:45-kor a koordinációt igénylő akadályokat egy ‘csapatok csapatához’ emelik, ahol a vezetők azon dolgoznak, hogy rendezzék vagy tovább eszkalálják a problémákat. Ez a megközelítés folytatódik, és 8:45-ig a végrehajtó akciócsoportnak megvan a listája azokról a kritikus problémákról, amelyeket meg kell oldania ahhoz, hogy a haladást sínen tartsa. A Saab Aeronautics a háromhetes sprintek közös ritmusával, a projekt főtervével, amelyet élő dokumentumként kezel, valamint a szervezet hagyományosan egymástól eltérő részeinek elhelyezésével – például tesztpilóták és szimulátorok fejlesztőcsapatokkal történő együttműködésével– koordinálja csapatait is. Az ebből létrejövő terméket a világ legköltséghatékonyabb katonai repülőgépének tartják.
Az SAP SE, a nagyvállalati szoftvercég a skálázott agilitás korai úttörője volt, mivel egy évtizeddel ezelőtt elindította a folyamatot. Vezetői először a szoftverfejlesztési egységekben terjeszkedtek agilisan – egy erősen ügyfélközpontú szegmensben, ahol tesztelhették és finomíthatták a megközelítést. Létrehoztak egy kis tanácsadói csoportot az új munkamódszer képzésére, coaching-jára és beépítésére, valamint létrehoztak egy transzparens eredménykövetőt, hogy mindenki lássa a csapatok eredményeit. „Az agilis termelékenység lenyűgöző növekedése konkrét példáinak bemutatása egyre nagyobb vonzerőt eredményezett a szervezetben” – mondta Sebastian Wagner, aki akkoriban a csoport tanácsadóinak vezetője volt. A következő két év során a vállalat bevezette az agilist a fejlesztő szervezeteinek több mint 80 százalékában, így több mint kétezer csapat jött létre. Az értékesítésben és marketingben dolgozók látták, hogy alkalmazkodniuk kell ahhoz, hogy lépést tudjanak tartani, ezért ezek a területek következtek. Miután a vállalkozás eleje nagy sebességgel mozgott, eljött az idő, hogy a hátsó rész is megtegye az ugrást, így az SAP belső IT-rendszerekkel foglalkozó csoportját is agilisra állították át.
Az USAA-nak jelenleg is több száz agilis csapata van, és további bővítést tervez. A cég – egy amerikai katonai személyzet kiszolgálására szakosodott pénzügyi szolgáltató cég – az agilis csapatok tevékenységét az üzletágakért és termékvonalakért felelős emberekhez köti. A cél annak biztosítása, hogy az eredménykimutatás egyes részeiért felelős vezetők megértsék, hogy a többfunkciós csapatok hogyan befolyásolják eredményeiket. A vállalat felsővezetői minden üzletágban vezérigazgatóként tevékenykednek, és teljes mértékben felelősséggel tartoznak az üzleti eredményekért. Ezek a vezetők több szervezetre kiterjedő keresztfunkcionális csapatokra támaszkodnak a munka nagy részének elvégzésében. Az USAA az élménytulajdonosokhoz rendelt technológiáktól és digitális erőforrásoktól is függ; a cél az, hogy az üzleti vezetők teljes körű erőforrásokkal rendelkezzenek az általuk vállalt eredmények eléréséhez.
A skálázott agilitás egyik definíciója: több agilis csapat létrehozása. Növeld a számukat ötvenre, százra vagy többre. Bővítsd az agilitás hatókörét, hogy a csapatok a szervezet különböző részeiben működjenek. Tanuld meg csapatok csapatait használni nagyon nagy projektek kezelésére. Sok különböző példát láttunk az ilyen típusú skálázásra, és a skálázott agilis esettanulmányok többsége erre összpontosít. Ez a fajta leírja a tipikus nagy szervezet eddigi tapasztalatait. (Agile at scale)
Az agilitás skálázásának azonban van egy másik megközelítése is, amely a legtöbb vállalat számára a láthatáron van. Ezt üzleti agilitásnak nevezzük, ami az agilis csapatok teljesítményének javítására összpontosít, miközben lehetővé teszi a bürokrácia és az innovációs erőfeszítések egymás mellett létezését. Az agilis vállalkozások az agilis üzleti rendszerek létrehozására összpontosítanak: a bürokráciát és az innovációs erőfeszítéseket szimbiotikus partnerekké alakítják, amelyek együttműködve jobb eredményeket érnek el.
Az a vállalat, amely nagyarányú agilis tevékenységre törekszik, valószínűleg továbbra is bürokratikus marad az üzleti élet alapvető megközelítésében. Az elsődleges cél az, hogy elegendő agilis csapatot hozzanak létre a pénzügyi eredmények javításához. A program nyereségességének biztosítása érdekében a menedzsment kombinálhatja a költségcsökkentő intézkedéseket, az agilisabb csapatok támogatásával. Az átalakítást jellemzően egy programkezelő, transzformációs iroda irányítja. A programiroda feladata az emberek viselkedések megváltoztatásának támogatása – agilis csapatok létrehozása, a támogatók előléptetése, valamint az átalakulásnak aktívan ellenálló emberek támogatása és segítése. Általában néhány év elteltével sokkal több agilis csapat lesz, és ezek a csapatok valószínűleg elég hatékonyan koordinálják majd egymást. Ennek ellenére szinte biztos, hogy a vállalatirányítás, működés, támogatás és kontroll bürokratikus rendszerében fognak dolgozni – egy olyan rendszerben, amely nagyjából ugyanúgy működik évtizedek óta.
A valódi üzleti agilitás viszont nem ilyen. Ha az agilitást skálázzuk, egyes vállalatok számára ez lehet a megfelelő választás. Agilis csapatok tucatjainak hozzáadása a hagyományos irányítási folyamatokon belül kezelhető és kreatív megoldásokkal a legtöbb akadály leküzdhető. A felsővezetők néhány tucat agilis csapat munkáját irányíthatják anélkül, hogy tönkretennék a csapatok teljesítményét vagy morálját. Mivel az agilis csapatok szinte mindig jobban teljesítenek, mint a hagyományos projektcsapatok, a csapat eredményei általában javulnak. Ennek a megközelítésnek azonban komoly kockázatai vannak. Idővel a szervezet nem agilis részeiben ellenállás alakulhat ki az agilis csapatokkal szemben. Az ezekben az egységekben dolgozók úgy érezhetik, hogy az agilis csapatok ellopják a legjobb embereket, ellopják a saját feladataik ellátására felhasználható pénzt, figyelmen kívül hagyják a költségvetési eljárásokat, veszélybe sodorják a helyes gazdálkodási gyakorlatot, és általában veszélybe sodorják a vállalatot. Az ebből eredő nézeteltérés arra kényszerítheti a szervezetet, hogy visszavonuljon a dolgok hagyományosabb módjaihoz, feláldozva az elért eredményeket. Létezik egy alternatív költség is: az a vállalat, amely a méretarányosságra korlátozza magát, feladja az üzleti agilitás létrehozásának potenciális előnyeit.
De a legnehezebb probléma a következő: bár az agilis csapatok minden eddiginél jobban és gyorsabban innoválnak, a vezetők valószínűleg azt tapasztalják, hogy a vállalat általános innovációs sebessége nem javul. Megvizsgálva ezt a problémát, felfedezhető az áramlási hatékonyság fogalma.
Az, hogy egy agilis csapat mennyi időt vesz igénybe egy innováció élesítéséhez, két tényezőtől függ: az innováción való munkához szükséges időtől és a másokra való várakozás idejétől. A várakozási időkbe beletartoznak az olyan működési folyamatok okozta késések, mint a stratégiai tervezési naptárak, a döntés-jóváhagyási folyamatok, a költségvetési és finanszírozási ciklusok, a szoftverkiadási ütemtervek, a jogi vagy szabályozási korlátok, az emberek elosztási folyamatai és tucatnyi egyéb tényező.
Egy vállalat áramlási hatékonyságát úgy számítják ki, hogy a munkaidőt elosztják a munkaidő plusz várakozási idő összegével. Az empirikus adatok azt mutatják, hogy a legtöbb vállalat áramlási hatékonysága ritkán jobb 15 vagy 20 százaléknál. Tehát még ha az agilis munka sebessége egyötödével javul is, a vállalat általános innovációs sebessége csak 3-4 százalékkal javulhat. Ez alig észrevehető különbség. Ezen túlmenően az is fokozhatja a frusztrációt, hogy ha több ember kilép, így kevesebb ember marad ugyanannyi munka elvégzésére. Ez lassabb sebességhez, hosszabb sorban álláshoz, hosszabb várakozásokhoz és több folyamatban eltöltött időhöz vezet. Tovább rontja a helyzetet, hogy a vezetők valószínűleg kétségbeesetten keresik a kihasználtság javítását és a költségek csökkentését, ezért a várakozási időt azzal töltik ki, hogy további projekteket adnak az embereknek. Ez egyszerre több feladat elvégzéséhez, multitasking-hoz vezet, ami növeli az átállási költségeket, csökkenti a termelékenységet, meghosszabbítja a várakozási időt, és tovább lassítja a fejlesztési ciklusokat. A végén az innováció sebessége valóban csökkenhet.
Az áramlási hatékonyság a legtöbb vállalatnál ritkán jobb 15-20 százaléknál
Íme egy beszédes példa, ami egy nagy pénzügyi szolgáltató-vállalat pilot-járól – a következő mobilalkalmazásának agilis módszerekkel történő – elkészítéséről szól. Természetesen az első lépés a csapat összeállítása volt. Ehhez költségvetési kérelmet kellett benyújtani a projekt engedélyezéséhez és finanszírozásához, hiszen több kisebb csapatnak is egyszerre kellett dolgoznia az alkalmazáson. A kérelem a következő éves tervezési folyamatban jóváhagyásért versengő beadványok közé került. Több hónapos felülvizsgálat után a cég végül jóváhagyta a finanszírozást. A pilot egy hatékony alkalmazást készített, amelyet az ügyfelek dicsértek, és a csapat büszke volt a munkájára. Az alkalmazás megjelenése előtt azonban át kellett mennie a sebezhetőségi tesztelésen egy hagyományos vízesés folyamatban (egy elhúzódó sorozat, amelyben a számítógépes kódo tesztelik a dokumentáció, a funkcionalitás, a hatékonyság és a szabványosítás szempontjából), és hosszú volt a sor a folyamathoz. Ezután az alkalmazást integrálni kellett az alapvető informatikai rendszerekbe – ami egy újabb vízesés folyamatot jelentett, hat-kilenc hónapos leállással. Végül a kiadáshoz szükséges teljes idő nagyon keveset javult.
Ismerős a történet? Ez a skálázott agilitás első jelentése (agile at scale). Hogyan kezeljük tehát az ilyen komoly kihívásokat? Ez a célja az üzleti agilitásnak.
A cikk forrásául szolgáló könyv: Darrell Rigby – Sarah Elk – Steve Berez: DOING AGILE RIGHT – Transformation Without Chaos
