Mizsei Szabolcs, a KÜRT Akadémia digitális transzformációs szakemberének írása

Az agilis működést nem lehet csak tankönyvekből megtanulni. Az élet legtöbbször nehéz helyzeteket teremt, ahol a szakmai tudásunkat, önismeretünket és megfelelő döntéshozásunkat is próbára teszi. A KÜRT Akadémia Agilis sztorik sorozata azért született meg, hogy konkrét történeteken és szituációkon keresztül mutassuk meg, milyen is az agilitás a mindennapokban.

Agilis szakembereink illusztrációként alaphelyzeteket hoznak, és elemzésükkel, fogalommagyarázattal, tanáccsal segítik, hogy egy-egy agilis alapérték ne csak egy szófordulat legyen, hanem valódi összetevője a mindennapi munkának.

Íme az első történetünk:

Az agilis módszertan szerint működő csapat négy hét kemény munka után sikeresen lerakta egy teljesen új digitális megoldás alapjait. Túl voltak az első mérföldkövön. Eufórikus elégedettség és öröm volt a teremben. Tíz napi megfeszített munka után a csapat ünneplésre készült. Még tortával és pezsgővel is készültek a várva várt vezetői elismerésre. Kézzelfogható volt az öröm; tudták, hogy most valami kiváló született.

A hosszúra nyúlt bemutató (review) után szót kért Ádám, a projekt felelős vezetője. A csapat izgatottan várta az elismerő szavakat. A rövid beszámoló és az üzleti célok után egészen váratlan dolog történt. Ádám rezzenéstelen arccal közölte a csapattal, hogy ha négy héten belül nincs konkrét eredményük, a projektet a költségmegszorítások miatt akár fel is számolhatják.

Megfagyott a levegő. Tapintható volt a feszültség. Kis csoportokban halkan beszélgetett mindenki. A délelőtti lendület egy pillanat alatt szertefoszlott.

Ádám transzparensnek szánt, motiválónak hitt szavai céljukat tévesztették. De vajon miért gondolta Ádám, hogy ez a megfelelő ideje és módja a lehetséges költségmegvonás és a csapat bizonytalan helyzetének bejelentésére? Miért gondolta, hogy ezt mindenképpen meg kell osztania a csapattal?

Ádám eddigi pályafutása során minden lépését gondosan megtervezte. Egyre nagyobb és komolyabb feladatokat kapott, kitartóan menetelt karrierlépcsőin felfelé. Mindig sokat dolgozott. Ő volt az, aki estéként utoljára hagyta el az irodát. Számára csak sikeres projekt létezett. Ezt a projektet is mindenképpen meg akarta menteni a bukástól.

Ádám vezetői eszköztárát is mindig fejlesztette. Tudta, hogy a transzparencia mennyire fontos az agilis csapatok életében. Fő gondolata most az volt, hogy ha megosztja a csapatot fenyegető körülményeket a csapat tagjaival is, akkor a munkatársak még jobban fognak küzdeni, és a legnagyobb akadályokat is le tudják győzni. Fel sem merült benne, hogy a bejelentése éppen ellenkező hatást válthat ki.

Ezeket a helyzeteket úgy hívjuk, hogy félreértett transzparencia.

A csapatnak biztosított transzparencia egy lényeges alapelv, azonban az agilis csapatoknak adott transzparenciát nem kell összekevernünk a vezetői őszinteség hagyományos értelmezésével.

A ceremóniák, a hibák ünneplése és értékelése, magunk és a csapatteljesítmény állandó javítása az agilis csapatmunka legfőbb erényei közé tartoznak, ám ez nem jelenti azt, hogy a fejlesztést érintő minden kockázatot kiteszek az asztalra.

Éppen ellenkezőleg. Ilyenkor a Product Owner „védőernyőkényt” működik, vagyis megvédi a teljesítő csapatot a külső körülményektől, és persze folyamatos erőfeszítéseket tesz a biztonság fenntartására (erőforrásalkukat köt, az üzleti-tervezési prioritásokat egyezteti a döntéshozókkal). Attól, hogy sprint közben egy döntéshozó megkérdőjelezi a fejlesztés egyes elemeit, vagy lefolyását, ezt a témát sem dobjuk be a daily standup-ba, mert nem oda tartozik.

Összefoglalva, a szolgáló vezetői szerepköreinkben biztosítanunk kell a fejlesztői csapat számára a napi munkavégzés feltételeit, de azokat a külső körülményeket, amelyekkel szolgáló vezetőként nekünk kell megküzdenünk, nem terheljük őket. A scope teljesítéséért PO-ként én felelek. Szállítom az ületi célnak megfelelő fejlesztéseket/funkciókat, védem a csapatot és viszem a termékvízió megvalósítása felé. Ha mindezeket összekeverjük, elvész a csapat pszichológiai biztonsága, a napi munkavégzésüket megterheljük a saját félelmeinkkel, visszaesik a termelési képesség és a végén pont ezért vallhat kudarcot a projekt. 

Persze sok olyan helyzet adódhat, amikor nehéz mérlegelni ezt a kettősséget. A Product Ownernek, vagy a csapatért felelős vezetőnek mindig védőernyőt kell biztosítani a csapat számára.

Az Ádáméhoz hasonló vezetői kihívásokat és nyomást vezetőtársainkkal kell kezelnünk. Ha azokat bevisszük a sprinttervezésre készülő és formálódó fejlesztői csapatba, elvész az említett biztonság.

Ádámnak azt tanácsoltuk, hogy hasonló helyzetben a fejlesztési prioritások újrahangolására és a gyorsabban szállítható értékekre koncentráljon, ezzel biztosítva a projekt folytatását.

Két fejlesztési időszak alatt egy motivált csapat nagyon sok eredmény szállítására képes.

Célozzuk meg azokat az eredményeket, amelyek a projekt továbbélését biztosíthatják. Mondjuk azt a csapatnak, hogy a következő két hétben újra kell terveznünk a feladatainkat, és előre kell vennünk pár olyan fejlesztést, amely már azonnal bevételt, üzleti értéket szállít. Ezzel Ádám feladattá tudja formálni azt, amit korábban maga fenyegetésként érzékelt. Ez a jó értelemben vett transzparencia. A megváltozott prioritások, a termékvízió átalakulása már kézzelfogható és konkrét változás, amit a fejlesztő csapat kezelni tud.  A félelmeinket és a lehetőséget, hogy elkerüljük a projekt leállítását, ezzel a lépéssel konkrét tevékenységekké és leszállítandó, akár élesíthető megoldásokká formálhatjuk.

Nehéz kérdés, hogy ha bizonyos információkat nem osztunk meg a csapattal, akkor még valóban transzparens-e a működésünk. A sprinten belüli transzparencia nem jelenti azt, hogy minden környezeti feltételről, kockázatról tájékoztatjuk a csapatot. Felmerülhet persze, hogy az elhallgatással éppen egy hierarchikus működést erősítünk, ami az agilis módszertan értékeivel szemben áll. Hogyan tudjuk eldönteni, hogy az adott információ a csapat működését az agilis transzparencia jegyében segíti? Mutatunk pár segítő kérdést:

• PO-ként működtetem-e a védőernyő-funkciómat, ha megosztok például egy adott erőforrás-kockázatot a csapattal?
• Újra tudom alakítani a prioritásokat annak érdekében, hogy akár néhány héten belül szállítsunk?
• A termékfunkciók áttekintése és kiigazítása (refinement) során elegendő információt adtam-e át a csapatnak? Szükség van-e további átalakításra a sprint tervezése előtt? Kérjek-e lehetőséget a tervezés előtt, akár az un. retrospektiv-ben a működés átalakítására? Van-e ide konkrét javaslatom, ami gyorsíthatja, javíthatja a következő sprint szállítását?

Szerencsére Ádám esetén is sikerült a pánikhangulatot egy közös esti beszélgetéssel feloldani, a rákövetkező napi tervezés során pedig meghatároztuk, hogy mely fejlesztések prioritásával biztosíthatjuk a csapat döntéshozói támogatottságát. Ennek köszönhetően a termékfejlesztés sikeresen folytatódott a következő hónapban!

Amennyiben mélyebben is érdekel a Product Owner szerepkör, és szívesen mélyítenéd tudásodat, akkor olvasd el képzésünk tematikáját.

Ha pedig vállalati szinten szeretnél fejlődni az agilis működésben, akkor Agilis vezetők a digitális korban képzésünket vagy Vállalati programjainkat ajánljuk, ha pedig az agilis transzformáció küszöbén állsz, akkor Agilis Transzformáció képzésünk adhat szakmai segítséget.