A cikk a létező leghitelesebb forrásból mutatja be az agilis céggé válás legfontosabb elemeit. Szerzői Jeff Sutherland, a Scrum egyik alapítója, illetve Hirotaka Takeuchi, a Scrum inspirációjául szolgáló „The New New Product Development Game” című tanulmány társszerzője. Mindketten az agilis irányzat legnagyobb úttörői közé tartoznak. Az eredeti cikk elérhető: hbr.org/2016/05/embracing-agile
A fordítást az Adaptive Consulting Kft. végezte.
Az agilis innovációs módszerek forradalmasították az információs technológiát. Az elmúlt 25-30 évben jelentősen növelték a siker rátát a szoftverfejlesztésben, javítottak a minőségen és a piacra lépés sebességén, és nem utolsó sorban egy erős lökést adtak az IT csapatok motivációjának és termelékenységének növeléséhez.
Mára az agilis módszerek – amelyek új értékeket, alapelveket, módszereket és előnyöket hoztak be a projektmenedzsment világába, és radikális alternatívái lettek a parancs-és-kontroll-stílusú menedzsmentnek – a különböző iparágak széles körében terjedtek el, mind a funkcionális, mind a vezetői szinteken. Néhány példa arra, hogy milyen széleskörben megtalálhatók az agilis módszerek.
Az amerikai National Public Radio alkalmazottai agilis módszerekkel szerkesztik új műsoraikat. A John Deere új gépei fejlesztésében, a Saab új vadászgépei gyártásában alkalamzza. Az Intronis – a felhő alapú háttér szolgáltatások kiemelkedő szereplője – az agilis módszerekkel dolgozza ki marketingstratégiáját. A C. H. Robinson HR részlegén alkalmazza az agilitást. A Mission Bell Winery pedig mindent agilis szemléletben végez a bor készítéstől, a raktárvezetésen át egészen a felsővezetéséig. Az agilis módszerekre támaszkodik a GE is, hogy minél gyorsabban vezesse át vállalatát a 20. századból 21. századba, egy “digitális ipari céggé” alakulva.
Az agilis szemlélet kiemeli az embereket saját funkcionális burkaiból és behelyezi őket egy ön-menedzselő és ügyfél-fókuszú multidiszciplináris csapatba. Az agilis személelt nem csupán arról szól, hogy felgyorsítja a nyereséges növekedést, hanem segít egy teljesen új szemlélettel rendelkező vezetői réteg kinevelésében is.
Az agilis módszerek terjedése megsokszorozta az izgalmas új lehetőségek számát. Mi lenne akkor, ha egy cég képes lenne 50%-os megtérülést elérni egy újonnan piacra lépő termékkel? Vagy mi történne, ha a marketing projektek 40%-al több vásárlót eredményeznének? Mi lenne, ha a HR 60%-al több újoncot érne el az elsőszámú célközönségéből? Mi lenne ha kétszer annyi alkalmazott válna érzelmileg is elkötelezetté a munkája iránt? Az agilis módszerek ezeket a szinteket hozták be és javítják folyamatosan az IT szektorban. Ezek a lehetőségek pedig egy cég más területein is ugyanígy adottak lehetnek.
Ám léteznek komoly akadályok.
Amikor vezetőket kérdezünk arról, hogy mit tudnak az agilitásról, a válasz általában egy kínos mosoly és egy megjegyzés, hogy “eleget ahhoz, hogy tudjam veszélyes”. Talán említenek egy-két agilis fogalmat („sprint”, “time-box”) és azt állítják, hogy a cégük így is egyre hatékonyabb lesz. De sosem vettek részt tréningeken, és éppen ezért nem is igazán értik az agilis megközelítéseket. Következésképpen, akaratlanul is egy olyan módon vezetik a cégüket ami szöges ellentétben áll az agilis elvekkel és gyakorlatokkal, valamint aláássa az alájuk rendelt agilis csapatok hatékonyságát.
Ezek a vezetők megszámlálhatatlan projektbe belekezdenek, egytől egyik sürgős és szűk határidővel, ahelyett, hogy priorizálnának és csupán két vagy három dologra fókuszálnának egyszerre. Elaprózzák magukat és a legjobb embereiket a túl sok projekt között. Állandó jelleggel, a kelleténél gyakrabban megbeszéléseken ülnek az agilis csapatok tagjaival, ezzel rákényszerítve őket arra, hogy félbehagyják munkájukat. Közülük sokan pedig túlságosan is belefolynak a csapatok munkáiba. Ezek a vezetők általában inkább beszélnek, mint meghallgatnak. Olyan ötleteket próbálnak a csapatokra erőltetni, amelyeket a tagok már korábban megvitattak és elvetettek. Rutinszerűen felülírják a csapatok döntéseit és felesleges ellenőrzési szinteket vezetnek be azért, hogy biztosítsák a hibák elkerülését. A legjobb szándék mellett lehetetlenítik el az agilis módszereket.
„Ezek a vezetők általában inkább beszélnek, mint meghallgatnak. Olyan ötleteket próbálnak a csapatokra erőltetni, amelyeket a tagok már korábban megvitattak és elvetettek. Rutinszerűen felülírják a csapatok döntéseit és felesleges ellenőrzési szinteket vezetnek be azért, hogy biztosítsák a hibák elkerülését. A legjobb szándék mellett lehetetlenítik el az agilis módszereket.”
Az agilitás lényege az innováció. Habár a módszer kevésbé hasznos egy rutinszerű műveletnél és folyamatnál, napjainkban a legtöbb vállalat változékony környezetben működik, ami megköveteli az újításokat. Nem csak hogy új termékekre és szolgáltatásokra van szükségük, de megújított folyamatokra is, nem utolsó sorban a szoftver eszközök gyors terjedésének köszönhetően.
Azoknál a cégeknél, ahol megteremtik azt a környezetet, ahol az agilitás kivirágozhat, ott a csapatok jelentősen gyorsabban teremtik meg az innovációt, mind a termék, mind a szolgáltatások kategóriájában.
Tanácsadói munkánk és a cégekről írt tanulmányaink alapján hat alapvető gyakorlatot határoztunk meg, amelyeket a vezetőknek magukévá kell tenniük akkor, ha ki akarják aknázni az agilitásban rejlő lehetőségeket.
1. Megérteni, hogy hogyan fejti ki a hatását az agilitás
Úgy tűnik néhány vezető az anarchiára asszociál akkor, amikor az “agilitás” kifejezést hallja. Szerintük ez azt jelenti, hogy “mindenki azt csinál amit csak akar”. Mások meg úgy értelmezik, hogy “csináljátok azt amit mondok, csak gyorsabban”. Ám egyik sem az agilitás.
Az agilitásnak számos fajtája létezik melyek hasonlóak, de részleteikben és hangsúlyaikban különbözőek lehetnek. Ezek magukban foglalják a Scrum-ot, ami egy hangsúlyozottan kreatív és adaptív csapatmunka a komplex problémák megoldására; a Lean fejlesztést, amely arra fókuszál, hogy folyamatosan csökkentse a veszteségeket; és a Kanban-t, amely az átfutási időkre és a folyamatban lévő munkák mennyiségének csökkentésére koncentrál.
Szerzőtársunk (Jeff Sutherland) egyike a Scrum módszertan alkotóinak, amelyet részben szintén egy a Harward Bussiness Review-ban megjelent 1986-os cikk inspirált, a “The New New Product Development Game”. Amit szintén egy másik szerzőtársunk, Hirotaka Takeuchi publikált. És mivel a Scrum-ot és annak deriváltjait ötször annyiszor alkalmazzák, mint más technikákat, ezért ezt a módszertant használjuk arra, hogy illusztráljuk az agilis gyakorlatokat.
A Scrum alapelvei
A Scrum alapelvei meglehetősen egyszerűek. Annak érdekében, hogy kifejlesszünk egy megoldást és kiaknázzunk egy lehetőséget, a szervezet létrehoz egy önálló kis csapatot (általában 3 és 9 fő közötti létszámmal), amelynek tagjai többnyire főállásban a megoldáson dolgoznak. A csapat kereszt-funkcionális és rendelkezik az összes készséggel, ami ahhoz szükséges hogy elvégezzék a feladatokat. Önmagukat menedzselik és szigorúan felelősséget vállalnak a munka minden egyes aspektusa iránt.
A megoldás gazdája, más szóval „product owner” felelős végső soron azért, hogy értéket szállítsanak az ügyfeleknek (ami magában foglalja belső vevőket és a jövőbeni felhasználókat is) és a megbízónak. Ezt a szerepet általában, egy az üzleti szférából jött személy tölti be aki megosztja az idejét a csapattal való közös munka és a kulcsszereplőkkel (ügyfelekkel, felső vezetőkkel és cég managerekkel) való koordináció között. A product owner egy átfogó listát készít az ígéretes lehetőségekről, elérendő célokról. Ezt nevezzük product backlognak. Majd ez a személy folyamatosan és könyörtelenül rangsorolja a backlog listát aszerint, hogy azok milyen becsült belső és külső értékekkel bírnak az ügyfelek és a vállalat számára.
Ugyanakkor a product owner nem mondja meg a csapatnak, hogy kinek mit kéne csinálnia, vagy mennyi ideig tarhat egy feladat elvégzése. Ehelyett a csapat készít egy egyszerű tervet, ami tartalmazza a részleteket és a különböző mozzanatokat, de csak azokra a feladatokra, amelyek már nem változnak meg a munka megkezdéséig. A tagok a legfontosabb feladatokat kisebb elemekre tördelik és eldöntik, hogy a csapat mennyi munkát képes elvégezni, hogy miként tudják kivitelezni azokat, majd meghatároznak egy világos definíciót a “kész” fogalmáról, és ezután elkezdik felépíteni a terméket rövid munkafázis ciklusokban, úgynevezett “sprintekben”. (Ezek mindenképpen egy hónapnál rövidebb ideig tartanak.)
A folyamatot egy facilitátor (gyakran egy képzett Scrum Master) irányítja. Ez a személy védi meg a csapatot a külső zavaró tényezőktől és elősegíti, hogy a csapat kollektív intelligenciája munkába lendüljön.
A folyamat mindenki számára átlátható. A csapattagok napi “stand-up”-okat tartanak, ahol beszámolnak az aktuális állapotokról és azonosítják az akadályokat. A nézeteltéréseket kísérletek végrehajtásával és visszacsatolásokkal oldják fel ahelyett, hogy véget nem érő vitákba kezdenének, vagy hatalmi pozíciókat próbálnának kiépíteni.
Kicsi, egyszerű prototípusokkal, néhány felhasználó, ügyfél bevonásával tesztelik az eredményeiket. Ha az ügyfelek kellően izgalmasnak találják amit láttak, a prototípus akár azonnal a nyilvánosság elé léphet (MVP), még akkor is, ha az néhány felső vezetőt nem győzött meg, vagy mások úgy gondolják a terméknek ennél több „csicsára” van szüksége a sikerhez.
A csapat ezután értékeli az előző sprint tapasztalatait és továbbfejlesztési irányokat határoz meg a termék további fejlesztésére és a saját működésének javítására is. Ezután, felvértezve az új tapasztalatokkal, megkezdik a következő legfontosabb backlog elemek megvalósítását.
Összehasonlítva a tradicionális menedzsment megközelítésekkel, az agilitás számos olyan jelentős plusz előnyt ígér, amelyek mind vizsgáltak, teszteltek és dokumentáltak. Növeli a csapatok produktivitását és a dolgozók elégedettségét. Minimalizálja azt a veszteséget, amit a fölösleges megbeszélések generálnak. Csökkenti a folyamatosan ismétlődő tervezéseket, a túlzott dokumentálást, a minőségbeli hibákat, és az alacsony értékű termékjellemzőkbe fektetett munka mennyiségét.
Az átláthatóság javításával és a változó ügyféligényekhez való folyamatos alkalmazkodási képesség fenntartásával növeli az ügyfelek elkötelezettségét és elégedettségét. Felgyorsítja a legértékesebb termékek és képességek piacra vételét, növeli a tervezhetőséget és csökkenti a kockázatokat.
A különböző szakterületekről érkező emberek egyenrangú együttműködésén keresztül szélesíti a szervezeten belüli együttműködést, a kölcsönös bizalmat és megbecsülést.
Végül, de nem utolsó sorban drasztikusan csökkenti azt az elvesztegetett energiát, amit a felsővezetők a projektek mikromenedzselésével töltenek. Ezzel lehetővé teszi számukra, hogy sokkal fontosabb kérdésekkel törődjenek, amelyeket csak ők képesek elvégezni: a vállalat víziójának kialakítása, a stratiégiai döntések meghozatala, a megfelelő emberek megfelelő pozícióba helyezése, a különböző területek közötti együttműködés javítása és a fejlődést gátló akadályok elhárítása.
2. Megérteni, hogy hol működhet az agilitás és hol nem
Az agilitás nem egy csodaszer. Leghatékonyabban és legegyszerűbben olyan környezetben implementálható, mint amilyenek a szoftverfejlesztés világában jellemzőek: A megoldandó probléma komplex; a megoldás részletei előre nem ismertek és az eredménytermékkel szemben támasztott követelmények nagy valószínűséggel változni fognak. A munka részekre bontható, a végfelhasználókkal történő szoros együttműködés (és a tőlük érkező gyors visszacsatolás) lehetséges. A kreatív csapatok jellemzően felülmúlják a parancs és irányítás elven működő csapatokat.
Tapasztalataink szerint, az imént felvázolt feltételek nem csupán a szoftverfejlesztésben, de számos más területen is ugyanígy adottak lehetnek. Például a különböző termékfejlesztési területeken, a marketing projekteknél, stratégiai tervezésnél, a logisztikánál és a forrás elosztási döntéseknél. Ezek a körülmények kevésbé jellemzőek a rutin tevékenységeknél, mint például a berendezések karbantartása, beszerzés, telesales, vagy a könyvelés.
Mivel az agilis szemléletre történő átállás megköveteli a tréningeket, a hozzáállás megváltozását és gyakran az új információs technológiák bevezetését, a vezetőknek mérlegelniük kell, hogy vajon a várható megtérülések igazolni tudják-e majd azokat az erőfeszítéseket és költségeket, amivel az agilitás bevezetése jár.
Az Agilitás működéséhez szükséges szervezeti feltételek:
| Feltételek | Kedvező | Kedvezőtlen |
|---|---|---|
| Piaci környezet | Az ügyfél preferenciák és megoldási módok gyakran változnak. | A piaci feltételek stabilak és kiszámíthatóak. |
| Együttműködés a vevőkkel | A szoros együttműködés és a gyors viszsajelzés megvalósítható. A folyamatok előrehaldtával az ügyfelek egyre pontosabban tudják, hogy mit akarnak. |
A végtermékkel szemben támasztott elvárások tiszták és nem változnak. Az ügyféllel való folyamatos együttműködés nem lehetséges. |
| Az innováció típusa | A probléma komplex, a megoldás részletei ismeretlenek, a projekt terjedelme nem határozható meg tisztán. A termék sepecifikáció változhat. A kreatív áttörések és a piacra vitel időpontja fontos tényező. A funkcionális területek közötti együttműködés létfontosságú. |
Hasonló munkát már végeztek korábban, a megoldás tiszta és egyértelmű. A részletes specifikáció és munkatervek nagy pontossággal előre elkészíthetők és változatlanul tarthatók. A probléma megoldható a funkcionális területek egymást követő, egymástól elkülönült lépéseivel. |
| A munka modularitása | Az egymásra épülő részeredmények értéket képviselnek, a felhasználók számár használhatók. A munka kisebb elemekre bontható és gyors, iteratív lépésekben előállítható. A késői változtatási igények kezelhetők. |
A felhasználók nem tudják a részeredményeket tesztelni addig, amíg az egész megoldás el nem készült. A késői változtatások drágák, vagy kivitelezésük lehetetlen. |
| Átmeneti hibák hatása | Tanulságként hasznosíthatók, kijavíthatók. | Katasztrofálisak lehetnek. |
Az agilitás sikere nagyrészt a lelkes résztvevőkön múlik. Egyik alapelve, hogy „építsük a projektet a motivált egyének köré. Biztosítsuk számukra azt a környezetet és támogatást, amire szükségük van, és bízzunk meg bennük, hogy majd jól végzik el a munkát”.
Mikor egy cég vezetése úgy dönt, hogy bevezetik az agilis szemléletet, a vezetők rákényszerülhetnek arra, hogy nyomást gyakoroljanak a ellenzőkre, vagy akár leváltsák őket. Persze jobb az önkéntesek támogatása, mint a kétkedők kényszerítése…
Erre egy példa, az OpenView Venture Partners befektető cég, amelynek körülbelül 30 vállalatban van befektetése. Miután több cégüktől is hallottak az agilitásról, Scott Maxwell a vállalat alapítója úgy döntött, hogy kipróbálja és saját maga kezdte el alkalmazni a metódusokat. Úgy találta, hogy ez a módszer néhány területen sokkal gördülékenyebbé tette a munkát. Az agilitás jól működött a stratégiai tervezésben és a marketingben, például ott, ahol a komplex problémákat gyakran modulokra lehet tördelni és kreatív multidiszciplináris csapatokra lehet bízni. Ugyanakkor nem működött az értékesítésnél: hiszen annak ellenére, hogy bármelyik értékesítői hívás módosíthat az értékesítési feladatokon, túl bonyolult és időigényes lenne óránként összehívni az értékesítő csapatot, megváltoztatni a backlogot és újraosztani az ügyfeleket.
Maxwell az OpenView többi cége számára – ahol még nem vezették be a módszert-, tréningeket tartott az agilis elvekről és gyakorlatokról, de rájuk bízta, hogy mikor és hogyan alkalmazzák azokat, feltéve ha szeretnék. Néhányuk azonnal beleszeretett és bevezették az agilis metódusokat, másoknál viszont a különböző prioritások miatt parkolópályán maradt a dolog. Az Intronis volt az egyik rajongó. Marketing osztályuk ekkor még elsősorban erősen csak a szakmai kiállításokra fókuszált, a sales osztály pedig úgy látta, hogy a marketing részleg túl konzervatív és nem hoznak eredményeket. Ezért a cég felvette Richard Delahaye-t, a web fejlesztőből lett marketinget, hogy vezesse be náluk az agilitást. Irányítása alatt a marketingesek megtanulták például, hogy hogyan kell webináriumokat hetek helyett, pár nap alatt összeállítani. (Az egyik gyorsan összeállított kampány: a CryptoLocker 600 feliratkozót hozott – ami a mai napig céges rekordnak számít náluk). A csapattagok pedig azóta is folytatják a naptárak és költségvetések gyártását az online marketing osztály számára, de jóval kevesebb ideig tart a folyamat és sokkal rugalmasabban alkalmazkodnak a váratlanul felmerülő problémákhoz. Az értékesítő csapat most sokkal elégedettebb…
3. Szűk körben kezdeni és hagyni, hogy elterjedjen a híre
A nagy cégek jellemzően komoly erőfeszítésekkel állnak neki bevezetni egy változtatást. Ám a legsikeresebb agilis bevezetések kicsiben kezdődnek. Ennek színtere gyakran az IT részleg, ahol a szoftver fejlesztők számára már nem ismeretlen a fogalom és pozitívan fogadják az ilyen irányú törekvéseket. Ezt követően az agilitás átterjedhet más területekre is, ahol az úttörő csapatok tagjai támogatják a többieket. Minden egyes siker, amit a módszernek köszönhetnek, jól láthatóan egy lelkes, az agilitásban hívő csapatot kovácsol, akik alig várják, hogy elmondhassák másoknak is, hogy miként működik a szervezetük az agilis menedzsment alatt.
Jó példája ennek a John Deere (amely mezőgazdasági felszereléseket gyárt), ahol eszerint az elgondolás szerint vezették be az agilitást. 2004-ben George Tome szoftverfejlesztőt, projekt menedzserré nevezték ki a John Deere IT csapatában. Elkezdte kis erőbefektetéssel alkalmazni az agilis metódusokat. Néhány év alatt fokozatosan, a Deere más szoftverfejlesztő részlegei is átvették a módszert. Az agilitás iránti egyre nagyobb érdeklődés jelentősen megkönnyítette a cég számára, hogy az üzleti tervezésben és a marketing osztályon is bevezessék az agilis módszereket.
2012-re Tome már menedzserként dolgozott az Enterprise Advanced Marketing R&D csoportjának csapatában, amely azért felelt, hogy olyan új technológiákat kutasson fel, amelyekkel forradalmasíthatják a John Deere kínálatát.
Jason Brantley, a csapat vezetője úgy érezte, hogy az akkori, a cégnél alkalmazott tradicionális projektmenedzsment lassítja az innováció folyamatát, ezért Brantley és Tome úgy döntött megnézi, miként lehet képes az agilitás felpörgetni a sebességet. Tome, az általuk szervezett agilis tréningre még további két csapat vezetőjét is meghívta.
Azonban az összes terminológia és példa, amelyekről a képzés során szó esett, mind a szoftverfejlesztés világából származtak, amit az egyik meghívott vezető, aki nem rendelkezett szoftveres háttérrel, képtelen volt befogadni és úgy nyilatkozott, hogy minden amit hallott nem más, csupán üres fecsegés. Tome felismerte, hogy más vezetők is hasonlóan reagálhatnak ezért azonnal szerződtetett egy agilis coach-ot, aki tudta miként lehet és kell együtt dolgozni olyan menedzserekkel, akik nem rendelkeznek szoftveres előélettel. Az elmúlt pár évben Tome és az említett coach folyamatosan képez ki csapatokat az R&D mind az öt központjában. Tome továbbá heti rendszerességel publikálni kezdett az agilis alapelvekről és gyakorlatokról, amelyeket hírlevelekben tesz közzé bárki számára, aki érdeklődik iránta, valamint ezeket megosztják a John Deere belső média felületein. John Deere alkalmazottak százai csatlakoztak ahhoz a vitacsoporthoz, amelynek témája az agilitás. „Olyan tudás-bázist akartam megalkotni, amely specifikusan a John Deere alkalmazottai számára készült, és a cégen belül bárki számára hozzáférhető és értelmezhető.” – állítja Tome. „Ez fektetheti le az alapjait annak, hogy az agilitás a vállalat bármely részlegén bevezethetővé válljon.”
Kiaknázva az agilis módszerekben rejlő lehetőségeket, az Enterpirse Advanced Marketing jelentősen lerövidítette az innovációs projektek ciklusidejét – néhány esetben több mint 75%-al.
Erre példa egy, a John Deere által még nem nyilvánosságra hozott fejlesztés, amelynek prototípusa körülbelül nyolc hónap alatt készült el. “Korábban, ha minden tökéletesen ment a tradicionális metódusok szerint – mondja Brantley-, a legjobb esetben is egy-másfél évig tartott, de sok esetben ez elhúzódott kettő-három évig is.” Az agilitás azonban más eredményeket is hozott. Növelte a csapatok elköteleződését a projektet és a vállalat iránt, valamit a hangulatuk, a csapaton belül mért elégedettség szintje is pillanatok alatt a cég alsó harmadából a top háromba ugrott át. Javult a minőség, valamint a sebesség (amelyet az egy sprint alatt elvégzett munkák összegében lehet mérni) is jelentősen megnövekedett, átlagosan több mint 200%-kal. Sok csapat esetében ez a szám a 400%-kot is elérte, de akadtak olyan is, ahol megütötték a 800%-kot.
Az ilyen sikerek felkeltik az emberek figyelmét. Manapság, Tome szerint, a John Deere szinte összes részlegén akad olyan személy, aki elkezdte használni az agilis metódusokat vagy legalábbis elgondolkozik azon, hogy miként tudnák hasznosítani azokat munkájuk során.
4. Hagyni, hogy a “Mester” csapatok testre szabják a gyakorlataikat
A japán harcművész diákok, különösen azok, akik aikido-t tanultak, gyakran elsajátítanak egy módszert, amit shu-ha-ri-nak hívnak. A shu állapotában a már bizonyított diszciplínákat tanulják. Mikor ezt elsajátították, beléphetnek a ha állapotába, ahol új dolgokba foghatnak és elkezdhetik módosítani a tradicionális formákat. Végül pedig továbbfejlődhetnek a ri állapotába, ahol olyan alaposan magukba szívták az alapelveket és gyakorlatokat, hogy már jogukban áll szabadon módosítani azokat, ha szükségesnek látják.
Az agilis innovációs módszerek elsajátítása is hasonlóan működik. Mielőtt elkezdenénk módosítani vagy személyre szabni az agilitást, az adott személy vagy csapat elsajátítja a széles körben használt metódusokat, amelyek cégek ezreinek hozták már meg a sikert. Például, bölcs dolog elkerülni a részmunkaidős csapatok kialakítását vagy a folyamatos rotációt a tagok között. Az tapasztalati tények azt mutatják, hogy a stabil csapatok 60%-al produktívabbak és 60%-al fogékonyabbak az ügyfelek visszajelzéseire, mint azok a csapatok, ahol folyamatosan cserélődnek a tagok.
Idővel pedig a tapasztalt szakemberek számára lehetővé kell tenni, hogy testreszabják az agilis eszköztárukat. Például az egyik elv azt javasolja, hogy a csapat az előrehaladást és az akadályokat folyamatosan láthatóvá tegye. Eredetileg, ennek a legnépszerűbb módja a színes cetlik pakolgatása volt egy nagy táblán a “to-do” oszlopból a “doing” és “done” oszlopba (ezt szokás kanban táblának nevezni). Sok csapat még mindig elkötelezetten kitart emellett a módszer mellet és élvezik, amikor a nem-csapattagok látogatják meg őket és szépen tudják mutogatni és megvitatni, hogy éppen mivel hol tartanak.
Mások viszont a szoftverek felé fordultak és képernyőkön követik le az eseményeket azért, hogy minimalizálják a feladatok rögzítésével töltött időt és, hogy az információ megosztható legyen szimultán is több helyen egyszerre.
(Mi, a fordítók a Scrum Mate projekt menedzsment alkalmazást ajánljuk: www.scrummate.com)
Azonban egy kulcsfontosságú útmutatást nem hagyhatunk figyelmen kívül ennél a filózofiánál: ha a csapat módosítani akar egyes gyakorlatokon, a változást mindenképpen tesztelni kell és az eredményeit mérni, hogy meggyőződjenek róla, hogy a változtatás javítja, nem pedig csökkenti az ügyfél elégedettségét, a munka sebességét és a csapat morálját.
A Spotify, a zene szolgáltató a tapasztalt agilis felhasználók egyik jó példája. A 2006-ban alapított cég születése óta az agilis gyakorlatok szerint működik, a vállalat egész üzleti modelljét tekintve, a termékfejlesztéstől a marketingen át, az általános menedzsmentig, igazodva ahhoz az irányelvhez, hogy folyamatosan jobb felhasználói élményt teremtsenek az agilis innováción keresztül.
Náluk a felsővezetők már nem határozzák meg az elvárt gyakorlatokat; éppen ellenkezőleg; ösztönzik a kísérletezgetést és a flexibilitást amíg az így születő változások konzisztensen egybevágnak az agilis elvekkel és igazolhatóan javítják az eredményeket. Ennek köszönhetően, módszerek sokasága terjedt el a vállalat mind a 70 “osztagában” (a Spotify által használt elnevezés az innovatív agilis csapatokra) és “szakaszában” (a cég terminusa a funkcionális kompetenciával foglalkozó részlegekre, például felhasználói felület fejlesztők, vagy minőségbiztosítók). Habár majdnem az összes osztag kis kereszt-funkcionális csapatokból áll és használnak vizuális folyamat nyomkövetést, rangsorolják a prioritásokat, adaptívan terveznek, és tartanak brainstorming eseményeket arra vonatkozóan, hogy miként javíthatnák a munkafolyamatokat, számos csapat kihagyja a “burndown” táblákat (amelyek mutatnák a teljesített és hátralévő munkákat), amik egyébként az agilis csapatok jellemző eszközei. Mint ahogy a sebességet sem mérik állandóan, nem tartanak haladás jelentéseket, és nem ugyanazokat a technikákat alkalmazzák arra, hogy megbecsüljék mennyi ideig fog tartani egy adott feladat. Ezek az osztagok letesztelték saját módosításaikat és úgy találták, hogy azok javítottak a korábbi eredményeiken.
5. Agilitás a legfelső szinteken
Néhány felsővezetői tevékenység nem passzol az agilis metódusokhoz: az olyan rutin és kiszámítható feladatok – mint amilyenek a teljesítmények értékelései, interjúk a sajtónak, a kötelező látogatások a gyártás-részlegen, ügyfeleknél és beszállítóknál, mind az előbb említett kategóriába esnek. De sok más, melyek vitathatatlanul a legfontosabbak, igenis összeférnek az agilis metódusokkal. Ezek magukban foglalják a stratégiák fejlesztését és a források elosztását, az áttörő innovációk támogatását és a szervezeti együttműködés javítását. Az a felsővezető, aki összekerül egy agilis csapattal és megtanulja alkalmazni azokat a diszciplínákat, amik az ilyesfajta tevékenységekhez kellenek, messzemenő előnyökre tesz szert. Személyes hatékonysága és morálja is javul amellett, hogy megtanulják beszélni azt a nyelvet, ami egy csapatot elkötelezetté tesz. Megtapasztalja a tipikus problémákat és megtanul felülkerekedni rajtuk.
Képessé válik felismerni és abbahagyni az olyan viselkedés formákat, amelyek akadályozzák az agilis csapatok működését. Elsajátítja az egyszerűsítés tudományát és a fókuszált munkavégzést. Ezáltal pedig javulnak az cég eredményei, növekedni fog a bizalom és a szervezet iránti elkötelezettség a szervezet minden szintjén.
Számos vállalat a vezetők idejének 25%-át (de volt ahol ennél is többet) átcsoportosította a funkcionális csoportoktól az agilis vezetői csapatokba. Ezek a vezetői csapatok vállalati körben rangsorolják a portfólió backlog-gokat, létrehozzák és koordinálják az agilis csapatokat a cégen belül bárhol azért, hogy a legmagasabban priorizált feladatokkal foglalkozzanak és szisztematikusan felszámolják azokat az akadályokat, amelyek a siker útjában állnak. Íme három példa arra, hogy a felső vezetők miként hasznosították az agilitást.
Felzárkózás a csapatokhoz
A Systematic, amely egy 525 alkalmazottat foglalkoztató szoftvercég, 2005-ben kezdte el alkalmazni az agilis módszerekt. Miközben a módszer elkezdett terjedni a szoftverfejlesztő csapatok között, Michael Holm, a vállalat igazgatója és alapítója, aggódni kezdett azért, hogy vezetőség lesz a haladás kerékkötője. “Az volt az érzésem, hogy csak mondom nekik “kövessetek”, itt vagyok rögtön mögöttetek. A fejlesztő csapat scrum-ot használt, mialatt a menedzsment csapat megrekedt az ósdi módszereknél.” – túl lassan változtak és túlságosan az írott jelentésekre támaszkodtak, amik állandóan idejétmúltnak tűntek. Ezért 2010-ben Holm úgy döntött, hogy a kilenc főből álló vezetőségét átformálja egy agilis csapattá.
A csapat újra-priorizálta a menedzsment tevékenységeket, megszűntették az ismétlődő riportok majd’ felét a maradékot pedig átalakították egy valósidejű rendszerré, mialatt növekvő figyelmet tudtak fordítani a kritikus üzleti problémákra, mint amilyenek például a kereskedelmi ajánlatok és az ügyfél elégedettség. A csapat minden hétfőt egy 1-2 órás meeting-gel kezdett, de ennek ütemét és határozatképességét túl lassúnak találták. Ezért inkább napi 20 perces, úgynevezett Stand-up-pokba kezdtek, amit mindig ugyanakkor, reggel 8:40-kor tartottak meg, hogy megvitassák ki mit csinált előző nap, mit tud csinálni aznap és hol van szüksége segítségre. Végül egyre gyakrabban kezdett a vezető csapat fizikai táblákat is alkalmazni, hogy mérjék saját aktivitásukat és az üzleti csapatok fejlesztésének hatását. Ma már más területek is, beleértve a HR, a jog és pénzügy részlegeket, nagyon hasonló módon működnek.
Gyorsítani a vállalati átalakulást
2015-ben a Genereal Electric “digitális ipari vállalat” iránnyal újra-brandelte magát, a digitális képességekkel rendelkező eszközöket fókuszba állítva. Az átalakulás részeként létrehozták a GE Digital-t, egy szervezeti egységet, amely a vállalat összes, közel 20.000 szoftverfejlesztéshez kapcsolódó munkát végző alkalmazottját tömöríti. Brad Surak, aki karrierjét szoftvermérnökként kezdte, most a GE Digital ügyvezető igazgatója, ám előélete révén közeli viszonyban áll az agilitással. Ezért kísérletezésekbe kezdett, hogy miként tudná a scrum-ot bevezetni azon vezetők körében, akik az ipari internet applikációk fejlesztéséért feleltek, újabban pedig ugyanezen metódusok bevezetését kezdte meg az új szervezeti egységek menedzsment folyamataiban, mint például az üzemeltetési riportok kezelései. Surak a termékgazda, egy vezető-mérnök a scrum master szerepet tölti be. Együtt készítik elő a sorba rendezett backlog elemeket a vezetői team által megoldandó problémákról. Ezek magukban foglalják például az adminisztrációs folyamat egyszerűsítését is, melyet a csapatoknak követniük kell hardver beszerzésekkor, vagy azokat a pitiáner árazási ügyeket melyek olyan termékeket érintenek amik több GE területtől érkező inputot igényelnek.
A scrum csapat tagjai két hetes sprinteket futtatnak és heti háromszor stand-up meetingeket tartanak. A folyamatban lévő feladataikat egy nyitott konferencia teremben elhelyezett táblán jelenítik meg, ahol bármely alkalmazott megtekintheti, hogy éppen mi hol áll. Surak szerint ez a módszer kiírtja azt a rejtélyt, hogy vajon mit csinálnak a vezetők egész nap, amíg az alkalmazott keményen dolgozik. “Az embereink tudni akarják, hogy tisztában vagyunk azzal, hogy számukra mik a fontosak” – állítja Surak. A csapat gyűjti az alkalmazottak elégedettségi kérdőíveit, a problémákat visszavezetik a kiváltó okokig, majd az eredményekről tájékoztatják az embereket ezzel is azt üzenve: “Meghallottunk titeket. Így fogunk javítani a dolgokon”. Surak hiszi, hogy ez képes lehet bebizonyítani egy szervezetnek, hogy a vezetők is ugyanabban a stílusban dolgoznak mint a mérnökök, ez pedig emelheti az alkalmazottak motivációját és elkötelezettségét az agilis technikák iránt.
A részlegek és funkciók összehangolása a közös vízióval
Erik Martella, a Mission Bell Winery (amely a Constellation Brands egy termelési üzeme) alelnöke és általános menedzsere, vezette be az agilitást és segítette hogy el is terjedjen az egész vállalaton belül. Minden részleg vezetője termékgazdaként teljesített feladatot, különböző agilis csapatoknál. Ezek az önálló csapatok lenyűgöző eredményeket hoztak, de Martella aggódott, hogy elaprózódik az ideje a csapatokkal való foglalkozás miatt és ezáltal a különböző részlegek, valamint vállalati prioritások nem lesznek mindig összhangban. Ezért elhatározta, hogy a részleg vezetőket egyetlen agilis csapattá szervezi, aminek a fókuszában azok a vállalati kezdeményezések állnak, amelyek a legjobb lehetőségeket teremtik a kereszt-funkcionális együttműködésre, mint amilyen például a raktározási folyamatok javítása.
Ez a csapat felelősséggel tartozik a backlog folyamatos vezétéséért, hogy az agilis csapatok a megfelelő problémákon dolgozzanak, és azok megoldásához minden szükséges forrást megkapjanak. A vezetői csapat tagjai továbbá megóvják a szervezetet az olyan „hobbi” projektektől, amelyek nem szolgálják a fontos célokat. Például, röviddel azután, hogy Martella elkezdte bevezetni az agilitást, emailt kapott a Constellation egyik vezetőjétől, melyben a feladó egyik személyes érdeklődésére számot tartó projekt lehetőségeinek feltárását javasolták. Korábban, Martella csupán azt válaszolta volna, hogy “Rendben, hamarosan belevetjük magunkat!”. Helyette azonban, azt válaszolta, hogy a borászat az agilis metódusokat követi: az ötletet hozzáadják a potenciális lehetőségekhez és megvitatják. Ez meg is történt, a vezetőknek pedig tetszett ez a módszer. Amikor informálta őket, hogy a javaslatukat alacsonyan priorizálták, elfogadták a döntést.
Az agilis csapatokban való munka a funkcionális menedzserek – akik ritkán tudnak kitörni a korlátaik közül napjaink túlspecializálódott szervezeteiben – általános vezetővé felkészítésében is segíthet. Az ilyen csapatok kapcsolatba hozzák őket más diszciplínák képviselőivel, megtanítják nekik az együttműködés gyakorlatait, és kihangsúlyozzák az ügyféllel való együttműködés fontosságát, amelyek a jövő vezetőinek eszközkészletéből mind elengedhetetlenek lesznek.
6. Elhárítani minden akadályt az Agilis mentalitás elől
A Scrum Alliance kutatása szerint (amely egy független nonprofit szervezet és több mint 400.000 tagot számlál) az agilis szakemberek több, mint 70%-a számol be feszültségekről a csapataik és a szervezet között. Kis adalék: mindannyian más munkatervek szerint, más sebességben dolgoznak.
Íme egy beszédes példa. Egy nagy pénzügyi szolgáltatásokkal foglalkozó céget vizsgáltunk, ahol a cég új mobil alkalmazásának fejlesztésére próbaképpen bevezették az agilis módszereket. Természetesen az első lépés a csapat összeállítása volt. Ehhez be kellett adniuk egy költségvetési kérelmet, hogy engedélyezzék és támogassák a projektet. A kérelem bekerült a csőbe, hogy megküzdjön a jóváhagyásért a soron következő éves pénzügyi tervezési folyamatban. Hónapokig tartó felülvizsgálati eljárás után a cég végül jóváhagyta a forrásokat. A kifejlesztett kísérleti termék egy hatékony alkalmazás volt, amelyet a felhasználók az egekig magasztaltak és a csapat büszke lehetett rá. Ám mielőtt az alkalmazás piacra lépett volna, még át kellett esnie egy klasszikus vízesés modell szerint kialakított sebezhetőségi teszten (ez egy elhúzódó folyamat, mely során a kód dokumentáltságát, a funkcionalitását, hatékonyságát és szabványoknak való megfelelőségét ellenőrzik). És az ellenőrzésre váró alkalmazások sora hosszú volt… Ezután az alkalmazást integrálni kellett a cég standard IT környezetébe, ami újabb 6-9 hónapos késlekedéssel járt. Mindezek után a termék piacradobásáig eltelt idő nagyon keveset csökkent a klasszikus módszerekhez képest.
Íme néhány módszer, amellyel elkerülhetők az agilis bevezetést hátráltató hasonló problémák.
Mindenkit képbe hozni
Az önálló, a nagy komplex probléma egy kis részére fókuszáló csapatok mindegyikének ismernie kell ugyanazt a céges prioritás-listát, és ez alapján kell dolgoznia még akkor is, ha nem az összes csapat alkalmazza az agilis módszereket.
Ha egy új mobil alkalmazás jelenti a top prioritást a szoftverfejlesztés számára, akkor ugyanennek kell a első helyen szereplnie a költségvetésnél, a sebezhetőségi tesztelőknél és az IT integrációnál is. Ellenkező esetben az agilis fejlesztések csak szenvedni fognak a megvalósítás során. Ennek biztosítása a szintén agilis módszerekkel működő felsővezetői csapat kiemelt feladata.
A struktúra helyett a szerepkörökön változtatni
Számos vezető feltételezi, hogy az egyre több kereszt-funkciós csapat létrehozása egyúttal szükségessé is teszi a szervezeten belüli komoly változásokat. Ez azonban csak ritkán igaz. Ugyanis a szabad kezet kapott kereszt-funkciós csapatok különböző definíciók szerint dolgoznak, amelyeknek szüksége van egyfajta mátrix menedzsmentre, ám ez elsősorban azt igényli, hogy a különböző diszciplínák megtanulják, hogy miként működjenek együtt inkább szimultán, mintsem elszeparáltan és szekvenciálisan.
Egy döntéshez egy főnök
Az embernek lehet több főnöke, de egy döntésnek nem. Egy agilisan működő modellben pedig muszáj, hogy kristálytisztán látszódjon, hogy ki a felelős egy kereszt-funkciós csapatért, ki válogatja és cseréli a tagokat, ki nevezi ki a csapat vezetőjét, és ki hagyja jóvá a döntéseket. Egy agilis vezetőségi csapat gyakran egy felsővezetőt nevez ki, hogy azonosítsa a kritikus problémákat, kialakítsa az ezek megoldását célzó folyamatokat és kijelöljön egy egyedüli gazdát minden egyes fejlesztési kezdeményezésre. Más felsővezetőknek pedig óvakodniuk kell attól, hogy ezeknek a termékgazdáknak a döntéseit megkérdőjelezzék vagy felülírják. Lehet iránymutatást és segítséget adni, de ha nem tetszenek az eredmények, a termék gazdát le kell cserélni – nem pedig ellehetetleníteni.
A csapatokra fókuszálni, nem az egyénekre
Az MIT Kollektív Intelligencia központja által készített tanulmányai bebizonyították, hogy az egyének intelligenciája hatással van a csapat teljesítményére, de a csapat kollektív intelligenciája még fontosabb. És ráadásul ezt sokkal könnyebb fejleszteni. Az agilis csapatokat folyamat facilitátorok segítik abban, hogy folyamatosan javítsanak a kollektív intelligenciájukon. Ők segítenek például tisztázni a szerepeket, konfliktus kezelési technikákat tanítanak és biztosítják, hogy a minden tag egyenlő mértékben szerephez jusson. Sokat segít, ha a termelékenység és a kihasználtság (mennyire elfoglaltak az emberek) mérése helyett a valódi megtermelt értékre és a csapat motivációjának mérésére helyezzük át a hangsúlyt. Ugyanígy jó ötlet a jutalmazási rendszer átalakítása úgy, hogy a csapat eredményesség nagyobb súllyal számítson, mint az egyéni teljesítmény.
Ne parancsolj, inkább kérdezz!
Geroge S. Patton Jr. tábornok vezetőknek szóló népszerű tanácsa, hogy soha ne mondd meg az embereknek, hogy miként csinálják a dolgokat. “Mondd el nekik, hogy mit kell elérniük, és ők majd meglepnek téged a találékonyságukkal”. Ahelyett, hogy parancsokat osztogatnának, az agilis szervezetek vezetői megtanulják hogy miként vezessenek egy csapatot kérdések által, mint például: “Mit javasolsz?” és a “Hogy tudnánk ezt tesztelni?”-jellegű mondatokkal. Ez a menedzsment stílus segít abban, hogy a hozzáértők képzett menedzserekké váljanak és ez az, ami elősegíti hogy a céges erőforrásokért és hatalomért küzdő szervezeti egységek együttműködő, keresztfunkcionális csapatokká érjenek.
Az agilis fejlesztés forradalmasította a szoftver ipart, amely vitathatatlanul gyorsabban és mélyebb változásokon ment keresztül az elmúlt harminc évben, mint bármely más üzleti terület. Most azonban az összes többi ipari szektor és üzleti részleg ugyanilyen változások előtt áll.
Ezen a ponton, a legnagyobb akadályt nem a jobb módszertanok iránti igény, a tapasztalati tényekkel bizonyított jelentős előnyök, vagy az agilis módszerek IT-n kívüli működőképességének belátása jelenti. Hanem a felsővezetők hozzáállása. Akik megtanulják kiterjeszteni az agilis módszereket a szervezet szélesebb körére, ők fogják elsőként találkozni a nyereséges növekedéssel.
Az eredeti cikk a Harvard Business Review 2016 májusi számában jelent meg.