Az agilis módszertan, agilis projektmenedzsment, agilis csapat, agilis szervezet és agilis coaching: Ha önnek ezek új fogalmak, cikkemből megismerkedhet velük.
Ha azonban igazán átfogó képet szeretne kapni az agilitás lényegéről, akkor az alábbi hat videót ajánlom önnek. Olyan módon közelítem meg a témát, ahogyan máshol még biztosan nem hallotta:
Agilis módszertan – 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
Az agilis módszertan a szoftverfejlesztésből jön
A szoftverfejlesztés hajnalán úgy vélték, hogy a fejlesztés lineáris folyamat, aminek az első szakaszaiban kell a megfelelő figyelmet és technikákat alkalmazni, és akkor biztos lesz a siker. Számtalan sikertelen szoftverfejlesztési projekt bebizonyította, hogy ez tévedés.
Ha ön 40+ éves, talán van olyan élménye, amikor a pályája kezdetén a cégénél szoftverfejlesztésbe kezdtek, ami teljes kudarccal végződött. Mire a szoftver elkészült, kiderült ugyanis, hogy nem is arra volt az ügyfélnek szüksége, amin a fejlesztők hónapokat dolgoztak. A karrierem szoftverfejlesztő cégnél kezdtem, és jól emlékszem ezekre. Feltételezem, hogy a sok fejlesztési kudarc is hozzájárult ahhoz, vagy inkább kikényszerítette a megoldást: az agilis módszertant.
Agilis kiáltvány
2001-ben a szoftveripar nagyjai együttesen előálltak egy „kiáltvánnyal az agilis szoftverfejlesztésért”. A kiáltvány honlapján található 12 „agilis alapelv” a következő:
- Legfontosabbnak azt tartjuk, hogy az ügyfél elégedettségét a működő szoftver mielőbbi és folyamatos szállításával vívjuk ki.
- Elfogadjuk, hogy a követelmények változhatnak akár a fejlesztés vége felé is. Az agilis eljárások a változásból versenyelőnyt kovácsolnak az ügyfél számára.
- Szállíts működő szoftvert néhány hetenként vagy havonként, lehetőség szerint a gyakoribb szállítást választva!
- Az üzleti szakértők és a szoftverfejlesztők dolgozzanak együtt mindennap, a projekt teljes időtartamában!
- Építsd a projektet sikerorientált egyénekre! Biztosítsd számukra a szükséges környezetet és támogatást, és bízz meg bennük, hogy elvégzik a munkát!
- Az információátadás fejlesztési csapaton belüli leghatásosabb és leghatékonyabb módszere a személyes beszélgetés.
- A működő szoftver az előrehaladás elsődleges mércéje.
- Az agilis eljárások a fenntartható fejlesztést szolgálják. Fontos, hogy a szponzorok, a fejlesztők és a felhasználók folytonosan képesek legyenek tartani egy állandó ütemet.
- A műszaki kiválóság és a jó terv folyamatos szem előtt tartása fokozza az agilitást.
- Elengedhetetlen az egyszerűség (a felesleges munkafolyamatok elhagyása) és az elvégzetlen munkamennyiség minimalizálásának művészete.
- A legjobb architektúrák, követelmények és rendszertervek az önszerveződő csapatoktól származnak.
- A csapat rendszeresen reflektál a saját működésére és mérlegeli, hogy miképpen lehet növelni a hatékonyságot, és ehhez hangolja és igazítja a működését.
A hagyományos felfogás szerint az elérendő cél alapján határozták meg az erőforrásigényeket, az agilis módszertan szerint viszont pont fordítva kell eljárni: az idő és a költségkeretek alapján kell meghatározni az elvégezhető feladatot.
Agilis szoftverfejlesztési módszerek
Az agilis kiáltvány után számos módszertani megközelítés látott napvilágot (Feature Driven Development, Scrum, Test Driven Development, Kanban, Crystal Clear), melyek közül a Scrum módszertan tett szert a legnagyobb ismertsége.
A „scrum” a rögbijátékban használt alakzat, amely a labda védelmét szolgálja a támadókkal szemben, akik természetesen mozognak. A Scrum agilis módszer köré komoly infrastruktúra épült ki az évek során. Az agilis módszer kézikönyve (Scrum Guide, lásd Sutherland–Schwaber, 2011) több nyelven elérhető, magyarul is, illetve a módszertan elsajátítása esetén többféle Scrum minősítés is szerezhető.
Scrum
A Scrum módszertanban egy iteratív fejlesztési ciklust sprintnek neveznek. Az adott sprint során a vizsgált időpontban még hátralevő, megvalósítandó szoftverfunkcionalitást „product backlog”-nak, vagy „sprint teendőlistának” hívják. A Scrum feltételezi, hogy nagy vonalakban ismert a sprint során elkészítendő termék terjedelme.
A Scrum kisebb fejlesztőcsapatokat (3–9 fő) tételez fel. Két szerepet különböztet meg, a „product ownert”, vagy magyarul „termékgazdát”, egy olyan felhasználót értve ez alatt, aki lényegében meg tudja fogalmazni a fejlesztendő szoftvertől elvárt funkcionalitást, illetve a „Scrum-mestert”, aki a Scrum szabályainak megértéséért és betartatásáért felelős.
A fejlesztőcsapat további tagjait a módszer nem különbözteti meg névvel. Mindenki fejlesztőnek számít függetlenül attól, hogy az adott platformhoz értő szoftverfejlesztő, üzleti elemző, tesztelő, dokumentumíró vagy a felhasználói élmény megtervezéséért felelős UX/UI designer.
A Scrum módszer sajátossága a fejlesztőcsapat önszerveződő volta. A Scrumban ennek megfelelően a csapat tagjai önként (önszerveződően) vállalják fel a sprint feladatait. Egy sprint időtartama legfeljebb egy hónap. Egy feladat időigénye pedig a sprint első részeiben legfeljebb egy munkanap.
Napi Scrumnak, más néven daily stand-up-nak, napi álló gyorsmegbeszélésnek nevezett értekezleteket tartanak, ami a következő 24 óra tervezését szolgálja. A napi Scrum legfeljebb 15 percig tarthat, minden résztvevőnek három kérdésre kell válaszolnia:
- Mit sikerült elvégeznie az előző megbeszélés óta?
- Mit fog csinálni a következő megbeszélésig?
- Milyen akadályozó tényezőket lát?
A sprint végén kerül sor a „sprint felülvizsgálatra” ahol áttekintik az elkészült és az el nem készült részeket, megvizsgálják ennek okait és lehetséges következményeit. Valamint, a ” sprint visszatekintésre”, vagy más néven „retrospektívre”, hol azt tekintik át, hogy miként működött a csapat együtt és mit kell tenni annak érdekében, hogy még hatékonyabbak legyenek. Azaz, felmérik a fejlesztőcsapat és a folyamatok javítását célzó intézkedéseket is.
Ezek után kerülhet sor a következő sprint megtervezésére, ahol gyakran olyan funkcionalitást határoznak meg, amely a sprint eredményes befejezése esetén azonnal használható.
Kanban
A Kanban is egy agilis módszertani eszköz, a Scrum után talán a második leggyakrabban emlegetett a szoftverfejlesztés területén. A Kanban is meglehetősen adaptív módszer, ami azt jelenti, hogy relatíve kevés a követendő szabály.
A két módszer közötti egyik különbség, hogy a Kanban megengedőbb a Scrum-hoz képest. Például, nincsenek meghatározott szerepkörök. Nincs időkeret közé szorított iteráció, azaz mi választhatjuk ki, hogy mikor tervezünk, mikor javítunk a folyamatunkon, és bocsátunk ki termékverziót.
Egy másik jellemző különbség a munkafolyamat-tábla használatában van. A Kanban-ban a munkafolyamat lépései korlátozottak. Egy adott munkafázisban bármely pillanatban csak annyi elem lehet, amennyit előzetesen meghatározunk.
Az agilis projektmenedzsmentet alkalmazók általában nem korlátozzák magukat egyetlen eszközre. Sok Kanban csapat tart napi megbeszéléseket, ami tipikusan Scrum-módszer.
Az agilis módszertan alapelvei
Tekintsük át az agilis módszertan alapelveit, melyeket ha a vezetéstudomány szemszögéből közelítünk meg, rájöhetünk, hogy nem minden új a nap alatt.
Az ügyféllel legyen megfelelő a kapcsolattartás:
Az agilis fejlesztés sajátossága, hogy szoros kapcsolatot tételez fel a szoftver felhasználója és fejlesztői között. Másképp fogalmazva, a fejlesztés csak akkor lehet eredményes, ha az érintettek közötti kommunikáció megfelelő mélységű.
Egy terv legyen hihető (reális):
Az innovatív (kockázatosabb, bizonytalanabb) feladatokat (projekteket) csak olyan időtávra érdemes részletesen megtervezni, amelyben a tervtől való eltérés mértéke várhatóan nem lesz elfogadhatatlanul nagy. Ez a tervezési alapelv a klasszikus projektmenedzsment eszköztárából sem hiányzik. Ami újszerűnek tekinthető az agilis világban, az a tervezés mindenhatóságába vetett hit megkérdőjelezése.
Önszerveződéssel javítsuk a csapat teljesítményét:
Az agilis munkavégzés további sajátossága, hogy a munkatársak maguk vállalkoznak egyes feladatok elvégzésére. Ez sem nevezhető új ötletnek, hiszen az önszerveződő csapatok előnyei már régóta ismeretesek.
Az önszerveződő csapatok jellegzetessége, hogy a csapat tagjai maguk döntik el, mely munkafázissal foglalkoznak, az egyes tagok képesek többféle munka ellátására, és maguk határozzák meg a jutalmazás és munkakövetés módját.
Az önszerveződő csapatokban dolgozók csapatkohéziója erősebb, és így termelékenysége gyakran meghaladja a szokványos munkaszervezéssel vezetett csapatokét. Nem meglepő tehát, hogy az agilis fejlesztési módszerek eredményesebbnek és hatékonyabbnak bizonyulnak, amennyiben az elvégzendő feladat természete lehetővé teszi annak önszerveződő csapat általi elvégzését.
Nyilvánvalóan a csapat tagjainak száma és személyisége is befolyásolja azt, hogy ez a fajta vezetési módszer alkalmazható-e. 10 főnél nagyobb létszámú csapatoknál gondokba ütközhet a kommunikáció. A csapat tagjainak képesnek kell lenniük arra, hogy elvégezzék a vállalt feladatot, és elég ambiciózusnak ahhoz, hogy kellően kezdeményezők legyenek.
A feladatok nyomon követése alapuljon tényeken, és legyen transzparens:
Mint korábban láttuk, a Scrum módszer előírja a napi Scrum alkalmazását, ami tulajdonképpen az előrehaladás kontrollja.
A csapat minden tagja láthatja, hogy a többiek mit végeztek el egy nap alatt. Az átláthatóságot segíti az is, hogy a csapat tagjai egy helyiségben dolgoznak. Az előrehaladást és a hátralevő feladatokat lehetőleg grafikusan, mindenki által jól látható helyen teszik közzé. Nincs kizárólag a feladatok követésével foglalkozó munkatárs, mindenkinek egyszerre kell dolgoznia és a nyomon követéssel foglalkoznia.
A vizualizáció, a nyomon követés eszköze:
Az agilis fejlesztések további jellegzetessége a vizualizáció, ami legtöbbször egy nyomon követést szolgáló tábla alkalmazását jelenti. Ez a módszer – feltéve, hogy a táblán a valósággal megegyező adatok szerepelnek – egyfajta demokratikus hozzáállást tükröz: mindenki számára egyértelmű, hogy ki mit végzett el, és mi lesz a következő lépés.
Ez tulajdonképpen a projekt követésének olyan eszköze, ami éppen a nyilvánossága miatt egyfajta kényszert is jelent a projekttagok számára, ugyanis nemcsak a vezető látja az elvégzett munkát, hanem a csapat összes tagja azonos képet kap.
Tartsunk önreflexiót:
Az agilis módszertan jellegzetessége a gyakori visszacsatolás, az önreflexió. A Scrum sprintjei végén előírt visszatekintés célja a munkavégzés módszerének javítása. A tanulás végső soron javítja a csapat (szervezet) eredményességét és hatékonyságát. A tapasztalatok kiértékelése szintén régóta része a projektmenedzsment technikai repertoárjának. Az agilis módszertanban ezek gyakorisága nagyobb a megszokottnál.
Az agilis módszertan leginkább a szoftverfejlesztés során terjedt el, de az elvei átvihetők más feladatokra is. Gondolja át, hogy az ön területén miként látja alkalmazhatónak, és milyen lépéseket tesz az agilis szemlélet megvalósítása érdekében!
Válasszon engem vezetői coachának, és segítek önnek olyan vezetői kompetenciákra szert tenni, amellyel magabiztosan állhat az agilis transzformáció élére, bármilyen vezetői szerepkörben is van.
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.
Az agilis módszertanról szóló fenti összefoglalást a Corvinus Egyetem Vezetéstudomány c. kiadványában megjelent kutatási munka alapján készítettem. Megjelenéshez a kiadvány szerkesztője hozzájárult.
