Villámelemzés – 15. State of Agile Report
Tizenötödik alkalommal jelent meg az agilis közösség egyik legátfogóbb áttekintő riportja, az ún. State of Agile Report.1 Míg az előző riport 2019 augusztusa és decembere közötti adatgyűjtésből származó elemzés, amely 2020 nyarán jelent meg (az addig jellemző tavaszi kiadás helyett), az idei mintavétel: 2021 februárja és áprilisa közötti. Így viszont abban a szerencsés helyzetben vagyunk, hogy tiszta képet kaphatunk arról, hogyan is változott a világnak ezen szegmense a járvány alatt, közvetlenül a koronavírus okozta változásokat megelőző állapothoz képest.
A State of Agile riportról pár szóban
Ez az általánosan elfogadottnak tekintett évenkénti részletes riport segít a trendek követésében, a piaci változások és reakciók felmérésében.
A riport a következő mintavételezéssel született:
– 1382 komplett felmérés érkezett.
– Több, mint 100 ország cégei vettek részt. Kontinentális eloszlásban: 37% észak-amerikai, 39% európai, 14% ázsiai, 10% egyéb.
– Ötből kettő válaszadó cége 1000 főnél kisebb.
– A válaszadók egynegyede 20 000 főnél nagyobb méretű cégben dolgozik.
– A válaszadók egyharmadának cégében 100 és 1000 fő között van a szoftver fejlesztéssel foglalkoztatottak száma.
– A válaszadók további egyharmadának cégében 100 fő alatt van a szoftver fejlesztéssel foglalkoztatottak száma.
– Az előző években a felmérésben szereplő cégek méretei, valamint a cégekben szoftverfejlesztéssel foglalkozó. csoport méretei közel azonosak – ez összehasonlíthatóvá teszi az évenkénti adatokat.
– A válaszadók 38%-a Scrum Master, 14%-a DevLead (vezető fejlesztő), 13% projektmenedzser.
Az idei riport abban több, hogy a kerek 15. alkalom okán számos visszatekintéssel, korábbi vagy az első éves riport számaira és a trendekre rávilágítással bővítették az idei kiadást – azon kívül, hogy tisztán leszűrhetőek a koronavírus világjárvány okozta eddigi változások. Alapvetően bizonyos statisztikák a riportban egyáltalán nem meglepőek, egyes értékek viszont annál inkább.
Elosztott csapatok szinte teljes térnyerése
A helyileg és földrajzilag elosztott csapatok aránya 89%-ra ugrott a legutóbbi 81%-ról. Ez abszolút rekord a felmérés (és az iparág) történetében (lásd 1. ábra). Az elosztott csapatok térnyerésére persze számítottunk.
Ráadásul a riport szerint csak a megkérdezettek 3%-a kíván visszatérni a teljes időben az irodában tartózkodáshoz. Érdekesség, hogy a korábbi 16% távolról dolgozó mellé a megkérdezettek további 25%-a jelezte, hogy egyáltalán nem kíván visszatérni az irodába a világjárvány után sem, holott előtte ott dolgozott. A válaszadók 56% a hibrid megközelítés mellett döntött.
1. ábra: Elosztott csapatokat alkalmazó vállalatok aránya
Agilis adaptáció – duplázódás. Agilitás számokban
Meglepő szám, hogy a szoftverfejlesztő csapatokban az agilitást adaptálók aránya a legutóbbi 37%-ról 2021-re 86%-ra ugrott (lásd 2. ábra). Hasonló duplázódás figyelhető meg a nem informatikai területeken is.
Ez zavarba ejtő növekedés, de próbáljuk meg a helyén kezelni. Vélhetően – lévén ez egy önbevallásos felmérés – az agilitást adaptálók ilyen volumenben nem tudták az agilis átállást véghezvinni teljes mértékben és sikeresen, hirtelen másfél év alatt. Illetve, számos esetben lehet, hogy a vállalatok azt hiszik az agilis átalakulás útján vannak, elkezdtek agilis praktikákat használni, vagy kénytelenek voltak a kényszerű távoli munkavégzés miatt számos agilis elemet beemelni a munkájukba, de alapvetően egy audit során kiderülne, hogy ezek a szervezetek messze vannak még az agilis működéstől.
Ellenben az önmagában is komoly eredmény, hogy azok a vállalatok, amelyek eddig az agilitástól távol tartózkodtak, ilyen nagy számban bevallottan és felvállaltan az agilis munkavégzés felé fordultak.. Ezen elhatározások tartósságáról nem vagyok meggyőződve, hiszen egy rosszul vagy csak bizonyos elemeiben bevezetett agilis működés messze nem fogja azokat az előnyöket hozni, amiket egy mélyreható transzformáció hozna, de az előrelépés így is szignifikáns.
A megkérdezett cégek 94%-a használ agilis praktikákat, 65%-a 3 évnél régebb óta. A megkérdezettek 18%-ának az összes csapata agilisan működik, a válaszadók 34%-ánál a csapatoknak több mint a fele agilis. Ez összesen 52%, ami igen impresszív arány. Hogy vállalaton belül mely területeken használják az agilitást (2. ábra)?
2. ábra
A módszertanok egymáshoz képest történő eloszlása sem változott jelentősen az elmúlt években (3. ábra): Folyamatos a Scrum térnyerése – jelenleg 66% – és az eXtreme Programming (XP) visszaszorulása: jelenleg 1%. A két módszertan hibrid alkalmazása a válaszadók 6%-ánál jellemző. A Kanban, és leánygyermeke a ScrumBan használatának aránya 6% és 9%, a többi módszertan összesen 12%-on osztozik.
3. ábra: Az alkalmazott agilis módszertanok eloszlása
Itt jegyzem meg, hogy a State of Agile riport tévesen a ScrumBan-t inkább a Scrum-hoz kapcsolja, de alapvetően a ScrumBan egy olyan Kanban, ami Scrum elemeket, praktikákat is tartalmaz, és nem fordítva.
Mely praktikákat használják a legtöbben?
A Scrum térnyerésével itt sincs meglepetés: a Daily Stand-up; Retrospective; Iteration Planning, Iteration Review áll az első négy helyen: 87-83-83-81%-kal. Immár a Release Planning is elérte az 54%-os arányt, amely már holisztikusabb megközelítést feltételez, illetve annak egyik eszköze. Ugyanígy üdvös a Product Roadmapping 52%-os térnyerése, és az Agile Portfolio Planning 32%-a. Ez utóbbiak azt jelzik, hogy a szigetszerű agilis adaptáció helyett egyre inkább a széleskörűbb átállás jellemző a cégeken belül és az említett eszközök is ezt a célt szolgálják.
Skálázás tekintetében továbbra is a Scaled Agile Framework (SAFe) előretörése látható: ezt jelenleg a válaszadó szervezetek 37%-a használja, mellyel messze a második helyezett Scrum@Scale 9%-os, az Enterprise Scrum 6%-os, és a köztudatban Spotify modellként elterjedt skálázási megközelítés 5%-os elterjedtsége előtt van.
A DevOps és értékteremtési lánc menedzsment előretörése
Szignifikáns az ún. DevOps-ot szem előtt tartók száma: a megkérdezettek háromnegyede (74%) tervezi ezt a közeljövőben bevezetni. A DevOps egy jógyakorlat-csokor, mely a fejlesztési (Development) és az informatikai működ(tet)ési (Operations) területeket hozza egymáshoz közelebb. Ez közös felelősséggel és tulajdonlással, magasfokú automatizációval és gyors visszajelzésekkel igyekszik egy fejlesztéskor született változtatást, újdonságot a lehető leggyorsabban és a legjobb minőségben élővé, a végfelhasználók számára használhatóvá tenni.2
A megkérdezettek 56%-a vezette be vagy tervezi bevezetni az ún. értékáram- vagy értékteremtési lánc menedzsmentet (eredeti nevén Value Stream Management-et, vagy VSM-et). További 23% pedig érdeklődik iránta. Az értékteremtési lánc menedzsment egy olyan Lean üzleti gyakorlat3, amely
– segít azonosítani az értékteremtési láncokat,
– az értékteremtési láncok vizsgálatát követően segít azok folyamatait javítani, működésüket optimalizálni,
– segíti az értékáramlást a szervezet számára, miközben a teljes szoftverszállítási életciklust irányítja (end-to-end),
– segít meghatározni a szoftverfejlesztési és szállítási ráfordítások (m)értékét,
– a csapatok a termék funkciókra és a termék tulajdonságokra vetített szoftverszállítási sikerességének mérése helyett, az értékteremtési láncokra fókuszálhatnak és ezáltal több energiát és időt fordíthatnak arra, hogy meghatározzák mi az ami működik. Így lehetőségük van eltérni attól, ami nem működik.
Ez két nagyon jó terület, amely az Agilitáshoz hasonlóan holisztikusan tekint a szervezetre. Ezeknek a területeknek az erőteljes térnyerése mindannyiunk előnyére válik szakmán belül és kívül egyaránt.
Miért vezetünk be agilist? És mit érünk el vele?
Ebben a kérdésben is évek óta szinte stagnál a válaszok aránya, és csak kisebb helycserék történnek az élen:
64-64% szeretné a változó prioritások kezelését megvalósítani az agilitás által, valamint felgyorsítani a szoftver szállítást. 47-47% szeretné fokozni a csapat produktivitását, valamint javítani az Üzleti terület és az IT együttműködését, igazodását egymáshoz. 42 és 41% szeretné az agilitással javítani a szoftver minőséget, valamint a szállítás előreláthatóságát. 40% szeretné a projekt átláthatóságát elérni. Továbbra is csak a válaszadók 23%-a szeretné a projekt költség csökkenése érdekében bevezetni az agilis működést. Üdvösnek tekinthető, hogy nem ez a mindent vivő legfontosabb indok a változtatásra (bár belecsomagolva ott szerepel(het) azért a csapat produktivitás növekedésében).
Akiknél bevezetésre került az agilitás, ott 70%-uknál javult a változó prioritások kezelése, valamint az átláthatóság. 66%-uk szerint javult az Üzleti terület és az IT együttműködése. Az agilis szervezetek 64%-ánál gyorsult fel a szoftverfejlesztés, 60%-nál javult a csapat produktivitása, 51%-nál a szállítás előreláthatósága. Ezeknek a cégeknek 45%-a nyilatkozott úgy, hogy a szoftver minőségében javulást ért el.
A fentiek alapján jól látható, hogy az elvárások az agilitással szemben kezdenek egyre inkább párban lenni az elérhető eredményekkel és a nyerességekkel.
Hogyan mérjük az eredményességet? Veszélyes tendencia
A cégek szeretnek mérni, mindent számokkal leképezni és egy repetitív, klasszikus feladat végzése során ezek a mérések alapvetően segíteni tudnak nekünk. Sőt, a trendek vagy a hibás folyamatok azonosításában is nagy segítségünkre vannak.
Ellenben az absztraktumokkal történő munkavégzés – amilyen egy szoftver fejlesztése is – kevéssé mérhető. Illetve, ha mérjük, elkövethetünk vele akár a rendszer egészét torzító baklövést is. Például egy atlétikai sportban az eredmény egzakt módon mérhető: időben, távolságban, magasságban. Míg mondjuk a sakkban ezek az értékek nem mérhetőek, hiszen annak íve van, lépései, stílusa, és a végén egyetlen eredmény van: nyert, vagy vesztett a játékos. A szoftverfejlesztés eredménye is hasonló: az ügyfél elégedett a végén, vagy sem? De ha a sakkban játék közben mérem a lépések során a táblán érintett mezők számát, a percenként leütött figurák számát, és még egyebeket, akkor torzulni fog a játék. Ugyanúgy, ahogy a versenysakk során bevezetett időmérés is drasztikusan módosította a játék stílusát, hiszen a sakkozók elkezdtek az eredményen kívül az időprésre is optimalizálni.
“Amire mérnek, arra optimalizálunk”.
A riportban egy aggasztó tendenciát véltem felfedezni, mégpedig azt, hogy mi alapján mérik a fejlesztés és a szállítás sikerességét a cégek (4. ábra).
4. ábra: Hogyan mérik a cégek a fejlesztés és szállítás sikerességét?
Az első három helyen a leszállított üzleti érték mennyisége (49%), az ügyfél elégedettség (szintén 49%) és a Velocity (45%) áll. Ezek közül csakis az ügyfélelégedettség van harmóniában az agilis alapelvekkel. Ezt nem részletezem, nézzük meg inkább a másik kettőt.
Leszállított üzleti érték: Azt, hogy melyik szoftverrész mekkora üzleti értéket jelent, az Üzleti terület határozza meg, az ügyféllel történt egyeztetések során. Ez egy szám, amit jellemzően az Üzleti terület ad meg.
Velocity: Ez a csapat által ‘story point’-ban megbecsült feladatok összege, melyet iterációról iterációra a csapat leszállít, gyakorlatilag egy csapat áteresztőképességét határozza meg.
Ez utóbbi kettő egy mérőszám, de mitől is függenek valójában? Amennyiben motivátorokat aggatunk egy mérőszámra (pl. ösztönző prémium, vagy az elbocsátás veszélye), azt előbb-utóbb el fogják érni. Mondok egy példát: Ha a scrum csapat (azaz a Product Owner, a Scrum Master, és a legfrissebb Scrum Guide-ban Developers-re átkeresztelt Development team együttesen) kap ösztönzőt, ami mondjuk a leszállított üzleti érték mértékéhez kötődik, akkor teljesen természetes módon a csapat (ebben az esetben különösen a PO) elkezdi felfelé korrigálni az egyes szoftverrészek üzleti értékét. Vagy azon dolgozik, lobbizik, hogy az ügyfél tegye ezt meg, mert így könnyebb lesz elérni a kívánt leszállítandó mennyiséget.
Ugyanez a helyzet a Velocity-vel. Ha a Velocitiy-hez kötjük egy csapat ösztönzőjét, azon kezdjük el mérni a teljesítményüket, biztosak lehetünk benne, hogy előbb-utóbb a fejlesztést megelőző becslések is elkezdenek felfelé korrigálódni, így elérve szállításkor a magasabb Velocity-t.
Amire mérnek, arra optimalizálunk. De valóban többet szállított az említett scrum csapat egyik vagy másik esetben? Több valós értéket kapott az ügyfél? Nem, nem kapott. Tehát sérültek az agilitás alapelvei, és az együttműködés az ügyféllel. Éppen ezért nagyon fontos, hogy a megfelelő dologra használjuk a méréseket és a megfelelő dologhoz kössük az ösztönzőket. Remélem, hogy ez a trend megfordul, és a cégek elszakadnak attól, hogy hibás – az agilitással ellentétes – gondolatokat ültetnek át a gyakorlatba.
Kihívások az agilitás elérésében
Itt látható átrendeződés az elmúlt évekhez képest. Az a vállalati kultúra, amely korábban egyértelműen a legfontosabb akadályok egyike volt, most 43%-on áll. Fő akadályként most a folyamatok inkonzisztenciája áll 46%-kal, a szervezeti ellenállás és az agilitással kapcsolatos tudás és tapasztalatok hiánya előtt (42-42%). Kiemelt akadályt jelentő páros, szintén a csúcs közelében, a nem elegendő menedzsment részvétel, valamint a kevés és helytelen menedzsment támogatás (41-40%).
Ez utóbbi azért is örömteli, hogy felkerült a lista élére, mert rávilágít arra, hogy erős menedzsment bevonódás és elkötelezettség nélkül, olyan nagy mélységű és széles horizontú változás, amilyet egy agilis átállás követel, nem tud végbemenni. Az esetek több, mint egyharmadában a tréningek és oktatások hiánya, gáncsolják el az agilis transzformációt (35%)valamint a szétdarabolódott (projekt vezérelt) eszközök és mérések (30%). Az utóbbi nagyon jellemző a klasszikus működésű cégeknél. Háromból egy agilis átállást ezzel szabotálnak is.
Összegezve: Az elosztott csapatok térnyerésére a világjárvány okán számíthattunk, ez nem okozott meglepetést. A szoftverfejlesztő csapatok agilis átállása, a korábbi penetráció több, mint megduplázódása meglepetés volt. Ebben visszarendeződés várható, hiszen a túl gyors és csak részelemeit implementáló agilis transzformációk jellemzően nem tartósan és csak korlátozott mértékben hozzák meg az agilitás által várható előnyöket. De a trend üdvözlendő, és az eddig elzárkózók is belekósolhatnak ebbe a tudatformáló utazásba.
A Scrum további terjedése is várható volt, akárcsak a SAFe skálázási térnyerése is. A DevOps és az értékteremtési lánc menedzsment (VSM) előtérbe helyeződése is felgyorsult a világjárvánnyal, mert az utóbbi fokozott kihívások elé állította a cégeket, amelyre az említett két technika bevezetése jó válaszokat tud adni.
Az agilis működés sikerességének mérésében tapasztalható trend aggasztó. Ebben mindenképp változásra van szükség, amit azzal lehet elérni, hogy az oktatásokat, képzéseket a vállalatok menedzsment rétegéhez is eljuttatjuk.
Szerző: Schweinitzer Zoltán, Sprint Consulting
Ahhoz, hogy tudjátok, hogy az Üzleti értéket illetve a Velocity-t mikor és mihez lehet jól használni, vagy hogy hogyan kell helyesen mérni az agilis működést, gyertek el gyakorlatorientált tréningjeinkre, és tegyük helyre együtt ezeket!
2 https://en.wikipedia.org/wiki/DevOps