/*Blog module replace 'read more' text*/

Az agilis squad áttekintése

AGILIS PROJEKTMENEDZSMENT BLOG

máj 1, 2024 | Projektmenedzsment blog

MINDSPIRE BLOG

Kövesse a MINDSPIRE közösségi oldalait!

Az agilis squad áttekintése

Bejegyzésünkben, amely egyben egy agilis cikksorozat első része is, felvázoljuk az agilis csapatok főbb jellemzőit, felelősségi köreit, optimális felépítését és gyakori kihívásait, illetve azt az összetevőt, ami nélkülözhetetlen a megfelelő működéséhez.

Előszó

Cikkünkben az agilitás, mint értékrend vagy gondolkodásmód alatt alapvetően az agilis manifesztó által megfogalmazott négy értéket és tizenkét alapelvet értjük.

Amikor pedig az agilis működést említjük, akkor elsősorban a Scrum keretrendszerre utalunk, amely ezen értékek és alapelvek figyelembevételével került megalkotásra.

Cikksorozatunk témái

1. Az agilis squad áttekintése
2. Az agilis user story
3. Az agilis csapatok teljesítményének mérése
4. Az agilis ceremóniák gyakorlati szemmel
5. Agilis dokumentáció… Valóban szükség van rá? (tervezett)
6. Daraboljunk, avagy mi fán terem az inkrementális fejlesztés! (tervezett)
7. Backlog vagy Blacklog? (tervezett)
8. Tervezzünk sprintet! (tervezett)
9. Hosszú távú tervezés vs. agilitás (tervezett)
10. Az agilis szerevezet HR szemmel (tervezett)
11. Az agilitás kihívásai nagyvállalati környezetben (tervezett)
12. Az agilis működés a home office árnyékában (tervezett)
13. Hol érdemes alkalmazni az agilis működést? (tervezett)

Az agilis csapatok alapvető jellemzői

Maga az agilitás rugalmas és sokszínű, így különböző szervezetekben és körülmények között eltérően is megvalósítható. A Scrum pedig egy olyan definiált szabályrendszer, ami segítséget nyújt számunkra abban, hogy az agilis értékek a mindennapi szervezeti működésünk részévé válhassanak.

Egy agilis squad, vagy Scrum Team a definíció szerint a Product Owner-ből (magyarul Termékfelelős, Termékgazda, vagy Terméktulajdonos), a fejlesztő csapatból és egy Scrum Master-ből áll.

Egy ilyen agilis csapat önszerveződő és keresztfunkcionális, ami azt jelenti, hogy:

  • a tagok saját maguk döntik el, hogy a rájuk bízott feladatot milyen módon valósítják meg,
  • a feladat elvégzéséhez szükséges valamennyi kompetenciával rendelkeznek,
  • illetve nem függenek olyan személyektől, akik nem részei a csapatnak.1

Egy agilis squad létszáma alapvetően a megvalósítandó feladat típusától és komplexitásától függ, de optimális esetben nem lehet kevesebb, mint három fő és nem haladhatja meg a nyolc, esetleg kilenc főt.

Maga a Product Owner, vagy a Scrum Master alapvetően ebbe a létszámba nem számít bele, kivéve akkor, ha ő maga is tevékenyen részt vállal a csapat feladatainak végrehajtásában. Nem kizárt, hogy a fejlesztő egyben Product Owner is legyen, vagy a Product Owner egyben Scrum Master is, amennyiben kellő tapasztalattal rendelkezik, valamint képes a különböző szerepkörökből adódó eltérő felelősségi köröket megfelelően kezelni.

1Forrás: scrumguides.org

De nézzük mik is ezek a felelősségi körök?

A Product Owner az a személy, aki a csapat által megvalósítandó feladatokat meghatározza és priorizálja, tehát ő dönti el, hogy a Scrum Team egy adott fejlesztési cikluson belül mivel és milyen sorrendben fog foglalkozni.

Azonban nagyon fontos kiemelni, hogy a definiálás alatt kizárólag azt értjük, hogy a csapatnak mit kell megvalósítania, a hogyan minden esetben kizárólag a Scrum Team hatáskörébe tartozik.

Tehát a Product Owner a felelős azért, hogy a csapat minden tagja pontosan értse a megvalósítandó feladatot, annak prioritását, valamint a cég céljainak megvalósulásában betöltött szerepét, de azt már nem határozhatja meg, hogy az milyen módon kerül megvalósításra, végrehajtásra. Ez alól csak az az eset jelenthet kivételt, ha a Product Owner is része a csapatnak, ám ebben az esetben és tekintetben az ő véleménye sem nyom többet a latban, mint a Scrum Team többi tagjának a meglátásai.

A Scrum Team számára kizárólag a Product Owner adhat feladatot, amiből az is adódik, hogy az ő felelősségi körébe tartozik az is, hogy a csapatot megóvja a külső negatív behatásoktól.

A Product Owner feladatai és kihívásai az agilis szkóp kontroll terén

Bár ez első olvasatra egyszerű feladatnak tűnik, azonban egy nagyobb méretű és ezáltal jellemzően hierarchikus felépítésű szervezetben napi szintű kihívást jelenthet egy Product Owner számára. Ha egy agilis csapatban a szervezet számára kritikus szakértői erőforrások vállalnak szerepet, akkor időről-időre megjelenhetnek olyan külső igények, amelyek más egységek céljainak megvalósítását szolgálják, de olyan új célkitűzések is megfogalmazódhatnak a felsővezetés részéről, amelyek egy ciklusban (legyen az egy sprint vagy egy negyedév) nem szerepeltek az adott Scrum Team által vállalt leszállítandó feladatok között.

Ilyen esetben mindig alaposan mérlegelni kell a körülményeket, hiszen az agilis alapelvek között szerepel, hogy a követelmények, így a célok is változhatnak, az ezekre adott gyors reakció pedig versenyelőnyt biztosít. Ennek megfelelően az ilyen módosításokat nem kell minden esetben azonnal elutasítani. Ahhoz, hogy ilyen esetben a megfelelő döntés születhessen, alapvetően két szempontot kell figyelembe venni:

  • Az egyik, hogy a már kitűzött célok és feladatok teljesítése mellett elvállalható-e az új tevékenység is. Ha erre igen a válasz, akkor látszólag mindenki boldog, bár ilyenkor jogosan merülhet fel a kérdés, hogy a csapat adott ciklusa megfelelően volt-e megtervezve. Bár vannak olyan esetek is, amikor egy-egy szállítás szkópja racionálisan csökkenthető annak érdekében, hogy az új igény megvalósítására is maradjon kapacitás.
  • A másik szempont pedig az, hogy az aktuális célok között vannak-e olyanok, amelyek a vállalat egésze számára kisebb értékkel bírnak, mint az az új cél, ami menet közben fogalmazódott meg. Ebben az esetben is befogadható az új feladat, de csak úgy, hogy ha azzal egyenértékben más feladatok kikerülnek az adott ciklus megvalósítandói közül.

Normál esetben egy már megtervezett és futó agilis sprint szkópja akkor sem változhat, ha a fentiek alapján a csapat elvállalja az új feladatot, legfeljebb egy következő sprintbe kerülhet be, vagy a már backlog-ban lévők mellé, esetleg azok helyett.

Éppen ezért fontos, hogy az agilis működésben kellően rövid fejlesztési ciklusokkal tudjunk dolgozni, illetve azokat megfelelően daraboljuk. Ennek részleteit most nem fejtjük ki, térjünk inkább vissza a csapathoz.

Az agilis squad optimális felépítése

Azt már tudjuk, hogy milyen hatáskörrel és felelősséggel rendelkezik egy Product Owner, de hogyan épül fel egy jó agilis squad?

Ahogy a definícióból is következik, a csapatnak minden olyan kompetenciával rendelkeznie kell, ami a feladat önálló leszállításához szükséges. Egy összetett tevékenység és komplex szervezet esetében ez azonban rögtön több kihívást is eredményezhet:

  • Ha a csapaton belül minden kompetencia rendelkezésre áll, akkor tartható-e a csapat optimális létszáma?
  • Amennyiben vannak olyan kompetenciák, amelyek a leszállítandó feladatnak csak egy nagyon specifikus részére korlátozódnak, mint például jog, kockázatkezelés, vagy IT biztonság, akkor az ilyen ismeretekkel rendelkező tagok számára a csapat tud-e folyamatos munkát biztosítani?
Agilis squad áttekintése

Hogyan lehet hatékonyan kezelni kompetenciákkal kapcsolatos kihívásokat az agilis csapatok esetén?

Ha bármelyik kérdésre a válasz nemleges, akkor arra a Scrum Team hosszú távú eredményes működése érdekében megoldást kell találni. Ugyanis mindkettő jelentősen rombolja az agilis értékek betarthatóságát. A túl nagy létszám hatványozottan csökkenti a hatékony, csapaton belüli kommunikációt, valamint az egyes tagok személyes felelősségvállalását a célok megvalósításában. Ha pedig van olyan tag, aki folyamatosan alulterhelt a csapaton belül, akkor az negatívan hathat a csoportdinamikára. Persze indokolt esetben, egy átmeneti időszakban mérsékelni lehet ezeket a negatív hatásokat, de mindig arra kell törekedni, hogy a csapat létszáma és összetétele az agilis értékek mentén kerüljön meghatározásra. Ennek elérése többféleképpen is megvalósítható:

  • Egyrészt szűkíthető egy-egy csapat szkópja, hatóköre, annak érdekében, hogy a rá bízott feladatokat önállóan is szállíthassa. Azonban a nagy szervezetekben ilyenkor felütheti a fejét egy másik probléma. Mégpedig az, hogy egy nagyobb feladaton több squad is dolgozik párhuzamosan, valamilyen valós, vagy mesterséges szegmentáció mentén, ami növeli koordináció komplexitását és nehezíti az információáramlást a különböző csapatokban dolgozó tagok között. Ráadásul, ha a csapatok közötti feladatmegosztás nem jól kerül meghatározásra, akkor függőségek alakulnak ki az egyes squad-ok között, ami szintén sérti az agilis alapelveket. De erről egy későbbi cikkben írunk majd részletesebben.
  • Másrészt növelhető az egyes csapattagok keresztfunkcionalitása. Ez azt jelenti, hogy a csapat létszámát kordában tartva, arra ösztönözzük az egyes csapattagokat, hogy az ismereteik, képességeik szélesítésével olyan feladatokat is képesek legyenek ellátni, amelyek alapvetően nem az eredeti kompetenciájukba tartoznak. Például egy üzleti szakértő elsajátíthat IT ismereteket, vagy egy fejlesztő kockázatkezelési tudásra tehet szert. Ez több szempontból is előnyös a szervezet és a működés számára. Ugyanis amellett, hogy csökkenti az egyes kompetenciában rendelkezésre álló erőforrások szűkösségét, és képes folyamatos fejlődési lehetőséget biztosítani a szervezetben dolgozó kollégák számára, folyamatosan növeli a munkavállalók értékét, illetve képessé teszi őket a rugalmas gondolkodásra és az egyes feladatok több nézőpontból történő megközelítésére is.

A fentiek alapján könnyen belátható, hogy alapvetően a második megközelítés az, amely mind a munkáltató, mind pedig a munkavállaló számára előnyökkel jár, ugyanakkor a gyakorlatban mégis inkább az első az, amellyel gyakrabban találkozunk. Ennek oka pedig egyszerűen az, hogy a második megközelítés mindenki részéről folyamatos áldozatokkal jár. A munkavállalónak nyitottnak kell lennie arra, hogy új ismereteket sajátítson el, nem ritkán akár a saját szabadidejét is rááldozva, míg a munkáltatónak szintén munkaidőt, energiát, valamint nem utolsósorban finanszírozást kell biztosítania.

A jól működő agilis csapatok titkos összetevője

Ezen a ponton pedig el is érkeztünk oda, ami a legfontosabb egy agilis szemlélet szerint működő csapat megfelelő működéséhez. Ez pedig nem más, mint az elköteleződés és az áldozatvállalás, mind a csapattagok, mind pedig a vezetőség részéről. Nem elég szertartásosan betartani a scrum keretrendszer által leírt szabályokat, törekedni kell az agilis értékek elsajátítására, illetve azokat tudatosan használni is kell a mindennapi munkavégzés során.

Egy agilis csapatban nem elég az, hogy valaki megfelelő minőségben leszállítja a rá bízott feladatokat. Mindenkinek folyamatosan arra kell törekednie, hogy átlássa és megértse a squad célkitűzéseit, ehhez pedig interakcióra, kritikus szemléletre, kreativitásra, széles látókörre és felelősségvállalásra van szükség. Az agilis működésben hiába a legjobb JAVA fejlesztő valaki, ha napi nyolc órában fejhallgatóval a fülén egyszerűen lekódolja azt, amit rábíztak, és semmiről sincs véleménye. Nem elég, ha azt gondolja, hogy nem neki kell kitalálnia, hogy hogyan kell optimálisan működnie egy üzleti folyamatnak.

Egy jól működő agilis squad-ban igazi csapatra van szükség, ahhoz pedig olyan tagokra, akik számíthatnak egymásra, képesek támogatni és terelni a többieket, őszintén megosztják a véleményüket egymással, képesek kompromisszumot kötni, valamint közösen küzdenek és hoznak döntéseket annak érdekében, hogy teljesítsék a Scrum Team céljait. Éppen ezért egy agilis csapat összeállítása során kiemelt szerepet játszik a megfelelő csapatdinamika kialakulása. A szakmai tudás természetesen elengedhetetlen, de sokkal fontosabb, hogy a csapattagok miként viszonyulnak egymáshoz, illetve hogyan képesek azonosulni a célkitűzésekkel.

Ha egy konkrét, sokak számára ismert példával kéne szemléltetni az ideális agilis squad-ot, akkor azt mondanám, hogy olyan, mint a Bosszúállók. Ott van Nick Fury, aki az ideális Product Owner. Informál, motivál, priorizál és megteremti a csapat számára a megfelelő körülményeket. Valamint ott vannak a szuperhősök, a csapat maga. Vasember, Amerika Kapitány, Thor, Hulk, Fekete Özvegy és Sólyomszem.

Külön-külön mindannyian remek képességekkel rendelkeznek, de együtt bármire képesek és legyőzhetetlenek, mert kiegészítik egymást és képesek kihozni egymásból a legjobbat. Kritikusak egymással szemben, ugyanakkor képesek alávetni magukat a közös érdekeknek, és nem utolsó sorban képesek egymásért is küzdeni.

Záró gondolatok

Az agilis squad az agilis működés szervezeti alapköve, amit ebben a cikkben igyekeztünk több aspektusból is bemutatni, azonban ez még mindig csak egy kis szelete az agilis szemléletnek és a Scrum módszertannak.

Ha szeretne többet is megtudni erről a témakörről, kövesse a MINDSPIRE közösségi profiljait, az elkövetkező hónapokban több cikkel is jelentkezünk majd az agilitás témakörében, az agilis ceremóniák bemutatásától az agilis tervezésen át egészen az agilitás támasztotta szervezeti kihívásokig.

Ha pedig támogatásra van szüksége az agilis projektmenedzsment kialakításában és működtetésében forduljon hozzánk bizalommal. Munkatársaink többéves tapasztalattal rendelkeznek az agilis működés terén. Az elmúlt években sikeresen vettek részt hagyományos projektszervezetek agilis transzformációjában, valamint agilis projektek leszállításában.

Gyenes Gergely

Szerző

Gyenes Gergely

Agilis projektmenedzsment témavezető

Gergely több mint 20 éves tapasztalattal rendelkezik a lakossági hitelezés területén. Egyaránt jártas az üzleti és az IT folyamatok tervezésében, valamint a projektmenedzsment, a tesztkoordináció és az adatelemzés terén is. Elkötelezett a csapatmunkában, folyamatosan támogatja és ösztönzi a kollégáit a lehető legjobb teljesítmény elérésére. Az elmúlt négy évben agilis product owner-ként dolgozott több lakossági hitelezési projekten, valamint részt vett szervezetek és projektek agilis transzformációjában is.

Ismerje meg a MINDSPIRE kapcsolódó szolgáltatásait:

 

Projektmenedzsment
szolgáltatások

Projektiroda
szolgáltatások

Az agilis squad áttekintése
Project management contact form

Kérdése vagy megjegyzése van a bejegyzéssel kapcsolatban?

Küldje el üzenetét és munkatársaink felveszik Önnel a kapcsolatot!

Projektiroda ikon

Legújabb Projektiroda referenciáink

Többet szeretne tudni Banki projektiroda szolgáltatásainkról?

További információkért kattintson ide:

Projektmenedzsment szolgáltatások ikon

Legújabb banki és biztosítói projektmenedzsment referenciáink

Többet szeretne tudni projektmenedzsment szolgáltatásainkról?

További információkért kattintson ide:

Share This