Hosszú távú tervezés az agilis működési modellben

Másfelől viszont az agilis szemléletben, ahol a változás érték, az el nem végzett munkamennyiség maximalizálására törekszik a szervezet, a szállításért és az előrehaladásért felelős alapvető egység a squad vagy a Scrum team, amely jellemzően két-három hetes ciklusokban tevékenykedik, ott ez az igény leginkább csak frusztrációt és felesleges adminisztratív feladatokat szül.

Hogyan oldható fel hát ez az ellentmondás, egyáltalán lehetséges-e ennek a kettősségnek minden érdekelt fél számára megnyugtatóan megfelelni? Azt gondolom, hogy talán ez az egyik legnagyobb kihívás, amivel az agilis személetnek meg kell küzdenie a multinacionális nagyvállalati környezetben ahhoz, hogy hosszú távon sikeres és meghatározó maradjon az adott szervezet életében és beteljesítse azokat az elvárásokat, amelyeket a cégvezetők támasztanak vele szemben. Cikkünkben ezt a dilemmát vizsgáljuk meg alaposabban.

A misszió és vízió szerepe a hosszú távú tervezésben

Az agilis backlog felépítéséről szóló cikkünkben korábban már ejtettünk szót az agilis csapat missziójáról. Ez az a definíció, amely pontosan meghatározza egy adott csapat tevékenységét, ez alapján dönthető el, hogy egy-egy user story az adott csapat backlogjában helyet kaphat-e vagy sem.

A vízió szintén egy definíció, ami azt határozza meg, hogy az adott csapat a misszióját teljesítve hová szeretne eljutni, mi az a végcél, vagy vágyott állapot, amely felé a csapat folyamatosan törekszik. Ez lehet egy teljesen konkrét meghatározás, mondjuk egy projekt squad esetében, vagy akár egy olyan elméleti cél is, amely ugyan soha nem érhető el, de amihez a csapat folyamatosan igyekszik minél közelebb kerülni.

Egy valóban agilis szervezetben minden csapatnak rendelkeznie kell a saját maga által meghatározott misszióval és vízióval. Fontos, hogy az összetettebb szervezetek esetében ezeknek a definícióknak összhangban kell lenniük a magasabb szintű szervezeti egységek definícióival, illetve az adott szervezeti egységben tevékenykedő többi agilis squad definícióival egyaránt.

Hosszú távú tervezés az agilitás szempontjából

Ha a víziók meghatározásra kerültek mind divízió, mind tribe, mind pedig squad szinten, ezek hierarchikusan is illeszkednek egymásba és összhangban vannak a szervezet stratégiai céljaival is, akkor az agilitás szempontjából a hosszú távú tervezés tulajdonképpen rendelkezésre áll.

Hiszen az agilis alapelvek alapján minden csapat kellő felhatalmazással rendelkezik, az azokban tevékenykedő szakemberek megfelelő tulajdonosi szemlélettel bírnak és pontosan ismerik a célt, illetve a menedzsment megbízik abban, hogy azt a szervezet számára legoptimálisabban igyekeznek megvalósítani és elérni.

Egy agilis utópiában minden bizonnyal így is van, de a valóságban egy kontrolling vezetőt vagy egy board tagot nem hiszem, hogy kielégít egy pusztán az egyes agilis csapatok szintjére vonatkozó „jövőbelátás”, ezért pedig a legkevésbé sem érheti őket szemrehányás.

Mégpedig azért nem, mert az agilis alapelvek és maga a Scrum keretrendszer is alapvetően a szervezet alapegységére, az agilis squadra vagy más néven Scrum team-re fókuszál. Míg ezek azt határozzák meg, hogy egy adott csapat hogyan tud minél hatékonyabban működni és szállítani, addig egy felsővezető számára a szervezetben tevékenykedő squad-ok összessége a fontos. Tehát az, hogy a szervezet számára rendelkezésre álló véges erőforrásokat úgy ossza el az egyes squad-ok között, hogy azok egységnyi idő alatt a lehető legnagyobb értéket állítsák elő. Ehhez pedig elengedhetetlen, hogy két-három hétnél előrébb tekintsünk, illetve a teljes szervezet szintjén tudjuk a hatékonyságot biztosítani.

• Ha túl rövid időszakra vonatkozóan kell megtervezni egy-egy squad feladatait és az ehhez szükséges erőforrásigényét, akkor olyan gyakran kell felülvizsgálni az egyes squadok működését és összetételét, ami negatívan hat az adott egység csapatdinamikájára, a folyamatos átszervezés pedig rombolja a morált és a tulajdonosi szemlélet kialakulását.
• Viszont az indokolatlanul hosszú időtávra való tervezés jelentős felesleges adminisztratív és morális terhet ró egy csapatra. Nem hatékony, ha egy csapat sprinteket tölt a hosszú távú tervezéssel, ahelyett, hogy valóban szállítana. Ráadásul minél hosszabb időtávra várja ezt el tőlük a menedzsment, annál kevésbé lesz pontos az előrejelzés. A tervek kényszeredett betartása rossz irányba tereli a csapat fókuszát, esetleges figyelmen kívül hagyása pedig felesleges frusztrációt okoz a csapatban dolgozók számára.

Milyen részletezettséggel érdemes tervezni az agilis modellben?

• Elegendő, ha megbecsülik egy hosszabb időszakon átívelő feladat nagyságrendi story pont értékét?
• Egy-egy ilyen projekt legyen előre feldarabolva story-kra és ezek a story-k legyenek előre besorolva jövőbeni sprintekbe?
• Esetleg minden egyes squad-ba rendelt kompetencia (üzleti elemző, fejlesztő, szoftvertesztelő stb.) esetében előre határozzuk meg a szükséges erőforrás mennyiségét és annak sprintenkénti eloszlását?

A régi iskola képviselői minden bizonnyal az utolsó pontban látják a megfelelő részletezettséget. Akkor érzik biztonságban magukat, amennyiben minél pontosabban előre meghatározásra kerül az embernap, az OPEX, a CAPEX és a PEREX, ha többszász soros Excel táblákban kimutatható, lehetőleg heti bontásban, hogy ki, mikor, melyik squad-ban, mennyi hozzáadott értéket fog teremteni, illetve az általa megtermelt eredmény, hogyan aránylik az általa felhasznált költségekkel.

Számukra az ember csak egy erőforrás, amit eltérő arányokban szét lehet osztani az egyes feladatok és squadok között, hogy azt minél hatékonyabban lehessen felhasználni a vállalat működése során. Aki reggel nyolctól minimum száz, de inkább százhúsz százalékon dolgozik délután ötig, hogy aztán a következő napot ugyanolyan pontossággal és hatékonysággal dolgozza végig.

Azonban ezt a merev, mechanikus megközelítést az agilis szervezetben el kell engedni!

• Elvárható egy agilis squad-tól, hogy két-három sprintre előre tervezzen és gondolkodjon? Abszolút igen!
• És az, hogy további négy-öt sprintre elegendő backlog elemmel rendelkezzen? Szintén igen!
• Sőt, egy érett csapat esetén még az is, hogy figyelembe véve az elmúlt időszak során a squad leszállító képességét (velocity), három-hat hónapos intervallumra előre, magas szinten tervezni lehessen, hogy milyen nagyobb funkciók / komponensek leszállítása reális.
• De az már nem várható el, hogy egy évre előre mondja meg, hogy melyik sprintben mennyi tesztelői, vagy üzleti elemző erőforrásra lesz szüksége. Sőt, ez valójában az agilitásban nem is értelmezhető.

A tervek és a tények összehasonlítása az agilis csapatok esetében

Dehogynem, csak másképpen! Nem elég, ha egy táblázatban összehasonlítjuk az előzetesen tervezett adatokat a tényekkel és az alapján mondjuk ki az ítéletet. Ennél ez lényegesen összetettebb és több odafigyelést igényel.

Azonban az agilis működés gyakori ciklikusságának és transzparenciájának köszönhetően ez sokkal hamarabb és hatékonyabban megtehető, mint a hagyományos működési modellben.

Az agilitás középpontjában a csapat áll, méghozzá egy olyan, amely önszerveződő és kellő felhatalmazással bír! Ugyanakkor ez nem jelenti azt, hogy semmilyen kontrollt sem lehet gyakorolni felette, hiszen a szervezettől, a menedzsmenttől kapja a felhatalmazását és a működéséhez szükséges erőforrásokat is. De ezt a kontrollt nem az előzetes hosszú távú részletes tervezés és annak minél pontosabb betartatása során kell gyakorolni, hanem a folyamatos szállítások elvárásával és nyomon követésével.

Ha a stakeholderek sprintről-sprintre nem látják azt a mértékű előrehaladást, ami szerintük elvárható lenne, akkor azt szóvá kell tenniük. Sőt, ha a dolgok továbbra sem a szerintük jó irányba mennek, akkor közbe is kell avatkozniuk, személycserékkel, vagy egyéb eszközökkel kell új lendületet adniuk a csapat számára.

A legvégső esetben a menedzsment akár meg is vonhatja a felhatalmazást a csapattól. Oszlassák fel a squadot, vonják le a konzekvenciákat és a szerzett tapasztalatok alapján lépjenek tovább. Ehhez a kontrollhoz persze az kell, hogy a stakeholderek a demok alkalmával folyamatosan nyomon kísérjék minden squad működését.

Összefoglalás

A hosszú távú tervezés a nagyvállalati működés szerves része, így valamilyen formában ennek végrehajtása az agilis szervezettől is jogosan elvárható. Fontos azonban, hogy a tervezett időszak hossza és mélysége is hozzá legyen igazítva az adott agilis szervezethez. Nem létezik ugyanis egy egységes, minden szervezet számára megfelelő standard ebben a kérdésben. Az agilitás megfelelő alkalmazása nem csak az operatív, „termelő” területektől, hanem a menedzsmenttől és a menedzsmentet kiszolgáló adminisztratív területektől is merőben új gondolkodásmódot vár el. Ha ezt nem sikerül meghonosítani a szervezetben, akkor sajnos az agilis működés hosszú távon kudarcra van ítélve.

Cégünk, a MINDSPIRE Consulting jelentős elméleti ismeretekkel és gyakorlati tapasztalatokkal rendelkezik az agilis projektmenedzsment terén a banki és biztosítói iparágakban.

Amennyiben kérdése lenne a cikkel vagy az agilis projektmenedzsmenttel kapcsolatban, kérjük vegye fel a kapcsolatot szakértőinkkel!