Agilis projektmenedzsment

Az ügyfeleim egy része fejlesztőmérnök, akik agilis projektmenedzsmentet alkalmaznak, elsősorban Scrumot. Sokat tanultam tőlük arról, miként alkalmazható az agilis módszertan.

Cikkemmel olyan vezetőknek szeretnék segíteni, akik agilis megközelítésmódokat keresnek, de nem feltétlenül a szoftverfejlesztésben szeretnék alkalmazni, hanem esetleg más területeken.

Íme egy infografika az alapinformációkkal: Agilis projektmenedzsment

Íme hat videó, ami minden részletre kiterjed az agilitással kapcsolatban:

Az agilis vezetés szemléletmódja – alapok
Az agilis projekt és a csapatvezetés
Az agilis vezetés mesterszintje az agilis kultúrateremtés
Miért sikertelen ma a legtöbb agilis szervezeti transzformáció?
Honnan hová tart a szervezeti világ?
Az agilis transzformáció kihívásai

Mire való az agilis projektmenedzsment?

Az agilis projektmenedzsment bármilyen olyan összetett probléma megoldására alkalmas, amikor

Néhány területen jól alkalmazható az agilis projektmenedzsment, ezek például a termékfejlesztés, forráselosztás, felforgató innovációk, marketingprojektek, stratégiai tervezés, szervezeti együttműködés javítása.

A rutintevékenységet igénylő feladatok esetén kevésbé van értelme, ezek pl. a könyvelés, karbantartási munkák, értékesítés, beszerzés, teljesítményértékelés.

Az iparágakat tekintve, a szoftverfejlesztésen kívül leginkább a pénzügyi és professzionális szolgáltatások, biztosítás, kormányzat, egészségügy, ipar és telekommunikációs területeken terjedt el.

Az agilis projektmenedzsment egy szemlélet

Vannak, akik nem egy szigorúan meghatározott módszertanról beszélnek, hanem sokkal inkább egyfajta hozzáállásról, kultúráról.

Lényege, hogy alaposan megértsük az ügyfeleink igényét, amelyre megoldást dolgozunk ki. A megközelítés azért agilis, vagy más szóval adaptív, vagy rugalmas, mert az ügyfél visszajelzései alapján gyors változtatást tesz lehetővé a fejlesztés alatt álló termékben vagy szolgáltatásban.

Többféle agilis módszertan létezik, amelyek keretrendszert biztosítanak a csapatoknak, amin belül azok szabadon kialakíthatják saját gyakorlatukat (pl. Scrum, Kanban, Lean startup, Design thinking).

A legelterjedtebb keretrendszer a Scrum, amit 1995-ben publikáltak először (az alkotói már 1993 óta használják). Ebben az írásban elsősorban ennek a keretrendszernek a bemutatására helyezem a hangsúlyt.

Mi tanulhatunk a Scrumból?

Nézzük meg, hogyan tudjuk alkalmazni a Scrum-elveket a saját projektjeinkben, amelyeknek – mint azt korábban is hangsúlyoztam – nem kell feltétlenül szoftverfejlesztéshez kapcsolódniuk.

Sprint

A Scrumban sprinteknek nevezték el azokat az egységnyi időtartamokat, amelyekben gondolkodunk. A sprintek 5, 10 napos, de egy hónapnál nem hosszabb időszakok, amelyeknek a végére működő terméket, prototípust kell előállítanunk. Ennek passzolnia kell a korábbi sprintek alatt létrehozott termékbe, szolgáltatásba, azaz egyfajta termék-, szolgáltatásbővítményt hozunk létre.

Agilis szerepkörök

Elméletben három szerepkört ismerünk, de a gyakorlatban számos példát látok arra, hogy két szerepkörrel is jól működnek a sprintek.

Csapat – szoftverfejlesztésben a fejlesztők alkotják a csapatot, de bármilyen szaktudású ember részt vehet. Az ideális létszám 5 fő körül van. Tapasztalatok szerint 9 fő felett a munka már nem szervezhető meg hatékonyan. A lényeg, hogy a tagok teljes munkaidős, belső munkatársak legyenek, akik olyan kompetenciákkal rendelkeznek, ami képessé teszi őket rendszeres időközönként, működő terméket szállítani.

A csapat önmenedzselő, és a szállítási képessége nem függ semmilyen külső szakértelemtől. A kompetencia-összetétel nyilván projektenként más és más. Az is előfordulhat, hogy egy csapattag több kompetenciával is rendelkezik. A tagok a feladataikat nem egymástól függetlenül, hanem szoros együttműködésben végzik.

Product owner – magyarul termékgazda, de mivel a kifejezés angolul terjedt el, ezért én is így használom. A product owner felel azért, hogy megfogalmazza a célokat, amelyeknek az eléréséért a csapat dolgozik.

Egy ún. product backlogban, teendőlistában vezeti a csapat összes feladatát. A listát folyamatosan rendezi oly módon, hogy mindig a legfontosabb feladat kerüljön a lista élére. A listában szereplő feladatokat mindenki számára érthetővé és elérhetővé teszi.

A feladatok kis méretűek. Ha egy feladat végrehajtásának ideje meghaladja a 6-8-12 órát, akkor kisebb feladatokra bontják szét. Így a feladatok egy munkanapon belül elvégezhetők és könnyebben kezelhetők. Ha túl sok az 1-2 óránál rövidebb feladat, akkor azokat csoportosítani szokták.

Scrum master – facilitátornak, csapatot szolgáló vezetőnek, vagy agilis coachnak is nevezik. Azért felel, hogy mindenki megértse, elfogadja és betartsa a Scrum szabályait. Feladata a megfelelő légkör, szellemiség biztosítása és a csapat önirányításának segítése.

Az ügyfeleimnél láttam példát arra, hogy a product owner és a scrum master szerepét egy fő látja el. Így is működik a projekt, mégis azt javasolom, hogy válasszuk szét a két szerepet, ha egy mód van rá. Különösen kezdő vezetők esetén.

Válasszunk product ownernek olyan vezetőt, aki céltudatos, erős a tervezésben és szívesen bíbelődik a részletekkel. Míg scrum masternek olyat, aki könnyen épít kapcsolatokat, képes másokat lelkesíteni és a csapatot összetartani.

Más-más karaktert és kompetenciákat igényelnek ezek a szerepek. Kezdő vezetők jobban teljesítenek, ha a személyiségükkel rezonáló szerepbe kerülnek, legalábbis vezetői karrierjük legelején.

Sprinttervezés

A legegyszerűbb, ha a sprinteket miniprojekteknek tekintjük. A sprinttervezés közös munka, minden csapattag részt vesz benne. A lényeg, hogy mindenki legyen képben azzal kapcsolatban, hogy milyen célokat szeretnének elérni és azt hogyan teszik.

Sprinttervezésre max. 8 órát javasolnak a szakemberek, ha egy hónapos időtávokban gondolkodunk, és arányosan kevesebbet rövidebb ciklusok esetén. Az ügyfeleim számára, akik kétheti ciklusokban dolgoznak, a 4 óra gyakran kevés. Nyilván projektje is válogatja, minek mennyi a valós időigénye. Ilyenkor érdemes megvizsgálni, hogy hatékonyan gazdálkodunk-e a rendelkezésünkre álló idővel.

Arra is látok példákat, hogy a csapat a „hivatalos sprinttervezést” megelőzően már elkezd tervezni. Mivel a Scrum egy rugalmas keretrendszer, ezzel semmi gond sincs. Egy másik elem, amiben, úgy látom, a csapatok hajlamosak eltérni a nagykönyvben leírtaktól, az erőforrásráfordítás-igény becslése.

A ráfordításigényt a gyakorlatban szívesebben becsülik meg időalapon, mint a feladat komplexitása alapján, amire a Scrum egyébként részletes útmutatást ad planning poker néven. A planning poker lényege, hogy a csapattagok a korábbi sprintek tapasztalatai alapján pontszámokat rendelnek az egyes feladatokhoz azok összetettségét figyelembe véve.

Napi Scrum

Más néven daily stand-up, ami egy 15-20 perces megbeszélés naponta, vagy hetente néhány alkalommal. Célja, hogy a csapattagok összehangolják a munkájukat annak érdekében, hogy a sprint végére elérjék a kitűzött célokat.

Szakemberek azt javasolják, hogy a napi Scrumot mindig ugyanabban a napszakban tartsuk, mindegy, mikor. E mögött az a praktikus megfontolás áll, hogy nem kell napi szinten egyeztetni a találkozókat. Ez az ügyfeleimnél is bevált.

A napi Scrum során a következő három sztenderdnek számító kérdés hangzik el, amit a csapattagok egyenként válaszolnak meg:

1. Mit csináltam az előző napi Scrum-megbeszélés óta, ami hozzájárult ahhoz, hogy a csapat elérje a sprint céljait?
2. Mit fogok tenni a következő megbeszélésig, ami előreviszi a projektet?
3. Látok-e bármilyen akadályt, ami veszélyezteti vagy megakadályozza azt, hogy a csapat elérje a sprint célját?

Ezeken kívül másról nem esik szó. Ha a csapat úgy dönt, hogy több időre van szükség egy téma megbeszélésére, akkor a scrum master kiír egy másik találkozót.

Sprintfelülvizsgálat

A sprint felülvizsgálatát minden sprint végén megtartják. Célja, hogy megvizsgálják, elérték-e a sprint céljait. Nem egy formális prezentációt kell elképzelni, hanem egy kötetlen beszélgetést. A csapat együtt végignézi a product backlogot, és ellenőrzi, hogy mi az, ami elkészült a listából. Végül aktualizálják a listát, ami kiindulópontját képezi a következő sprintnek. Általában 4 órásra tervezik a visszatekintést (egy hónapos sprint esetén).

Sprintvisszatekintés, más néven retrospektív

A hagyományos szervezeti kultúrákban kevésbé ismert értekezlettípus, az ún. visszatekintő, vagy más néven retrospektív megbeszélés. Lényege, hogy a csapattagok felülvizsgálják a legutóbbi együttműködés mikéntjét, és megállapítják, hogyan dolgozhat a csapat jobban a következő időszakban.

A csapat felidézi az elmúlt egy-két hét együttműködésének emlékeit, és elgondolkozik azon, mi ment szemmel láthatóan jól, és mit tenne legközelebb másként. Utána megegyeznek, mi az a néhány dolog, amelyre figyelni fognak a következő időszakban.

A módszertant a szoftverfejlesztésben dolgozták ki, de a hagyományos szervezetekben is jól tud működni, hiszen ott is helye van annak, hogy a csapatok a saját működésüket értékeljék, és kutassák a hatékonyságuk növelésének lehetőségeit.

A visszatekintő megbeszélést általában a scrum master vezeti, akinek az a dolga, hogy az eseményt megszervezze és a csapattagokat hatékony együttműködésre bírja.

Agilis eszköztár

Az átláthatóság megteremtésének eszközei a vizuális táblák, grafikonok. Ezek közül az egyik legjelentősebb a burn-down chart, vagy munkahátralék- grafikon, ami azt mutatja meg, hogy a feladatokból mennyit végeztek el, és még mennyi ráfordításra van szükség a sprint végéig.

Az egyik ügyfelem (András) felettese, a vezetői coachingot megelőzően azzal a kéréssel fordult hozzám, hogy találjunk ki valamit, amivel a felső vezetők számára is átláthatóvá válik, mivel foglalkozik András csapata. Nem érti, mitől annyira leterheltek, és miért nem tudják az ügyfelek kéréseit azonnal kielégíteni.

A szoftverfejlesztőknél előfordul (a gyors technológiai fejlődésnek köszönhetően egyre gyakrabban), hogy a fejlesztők feletti, néhány szinttel magasabban lévő vezetői réteg már alig látja át, hogy mit csinálnak az embereik. Következésképpen becsülni sem tudják, hogy mi mennyi ráfordítást igényel.

András csapata nem ismerte az agilis módszertant, de nyitott volt arra, hogy megvizsgálják a burn-down chart elkészítésének a lehetőségét. Sok munkával Excelben elkészítették, és óriási sikert arattak vele. Lehet, hogy a felső vezetők nem értették a részleteket, de vizuálisan átlátták a csapat tevékenységét, és ez megnyugtatta őket. A burn-down chart a projekt láthatóvá tételének egy kiváló, modern eszköze (is).

Az agilis projektmenedzsment Scrum keretrendszere, amelyet a fentiekben bemutattam, a szoftverfejlesztésben terjedt el, de érdemes átvenni belőle elemeket, vagy a teljes megközelítésmódot más projekt esetén is.

Köszönöm, hogy elolvasta írásomat. Ha tetszett, kövesse szakmai tevékenységemet, és ossza meg cikkeimet másokkal is, ha úgy érzi, hogy számukra is hasznos lehet.
Írásaim saját szellemi termékeim, ezért kérem, ha felhasználja, azt a szerzői jog tiszteletben tartásával tegye. Az eredeti tartalommal, a szerző és a forrás megjelölésével idézze, ahogy én is teszem.

Válasszon engem vezetői coachának, és segítek önnek olyan vezetői kompetenciákra szert tenni, amellyel magabiztosan állhat az agilis átalakulás élére, bármilyen vezetői szerepkörben is van.

Írjon a kranitz.eva@vezetofejlesztes.hu-ra, vagy hívjon a 70 6363 538-as telefonszámon.