Az agilis módszer a rugalmasság, a folyamatos fejlesztés és az ügyfélközpontúság elvein alapul. Ezek az elvek időtállóak, és akkor is relevánsak maradnak, ha a konkrét módszerek vagy keretrendszerek fejlődnek. Az agilis módszerekkel kapcsolatos folyamatos viták és viták csak azt bizonyítják, hogy a módszer releváns és képes alkalmazkodni a változó körülményekhez.
A Scrum az egyik legnépszerűbb módszer az agilis elvek alkalmazására. A Scrum útmutató keretet biztosít a csapatok számára a munkájuk megszervezéséhez és strukturálásához. Az probléma azonban akkor merül fel, amikor a csapatok túl szigorúan követik ezt az útmutatót. Az agilitás az alkalmazkodóképességről és a változásokra való reagálásról szól, míg a Scrum-szabályok merev betartása rugalmatlanságra ösztönöz.
A rugalmasság elvesztése: Az agilis csapatokat arra ösztönzi, hogy a projekt igényei és a visszajelzések alapján alkalmazkodjanak és fejlődjenek. A Scrum szigorú betartása korlátozhatja ezt a rugalmasságot, és a csapatok kevésbé reagálnak a változásokra.
Az agilis értékek félreértése: A Scrum szabályainak szigorú betartása miatt a csapatok szem elől téveszthetik az agilis munka mögöttes értékeit, mint például az egyének és az interakciók a folyamatokkal és eszközökkel szemben.
Mindenki egyforma megközelítés? Az agilis megközelítés elismeri, hogy minden projekt és csapat egyedi. A merev Scrum megközelítés figyelmen kívül hagyja ezt a sokféleséget, és nem optimális eredményekhez vezethet.
Hogyan fogadhatjuk el igazából az agilitást?
Ahhoz, hogy az agilitás valódi szellemét átvegyük, túl kell tekintenünk a Scrum szabályain.
Alkalmazkodás és testre szabás: A Scrumot a projekt és a csapat sajátos igényeihez kell igazítani anélkül, hogy szem elől tévesztenénk az agilis módszertan alapelveit.
Az értékekre és elvekre való összpontosítás: Koncentráljunk az agilis értékekre és elvekre, és a Scrumot eszközként használjuk, ne öncélúan.
Folyamatos fejlesztés: A kísérletezés és a tanulás kultúrájának ösztönzése, a folyamat folyamatos értékelése és javítása.
Az agilis metódus még korántsem halott; továbbra is hatékony filozófia, mely segít a szervezeteknek gyorsan és hatékonyan reagálni a változásokra. A kihívást az jelenti, hogy megtaláljuk a megfelelő egyensúlyt egy strukturált módszer, például a Scrum követése és az agilis módszer központi elemét képező rugalmasság és alkalmazkodóképesség fenntartása között. Az agilis alapértékekre és alapelvekre összpontosítva olyan környezetet teremthetünk, amelyben a csapatok valóban gyarapodhatnak, és alkalmazkodhatnak a modern világ folyamatosan változó igényeihez.
Miért nem működik az agilis metódus egy szervezetben?
Az munkatársai havonta vagy kéthavonta szükségét érzik annak, hogy kijelentsék, hogy „az agilis metódus halott”? Az agilitás halálát több igazgatótanácsban is divat manapság hirdetni. Tehát az agilis módszer valóban idejét múlt? Ezzel nem értünk egyet. A „rossz agilitás” vagy „ál-agilitás” vagy „a környezetnek játszó agilitás” nyilván már ezer halált halt: csak azért, hogy a következő lelkes, digitálisan átalakuló szervezetben újraéledjen, ahol az agilitás és gyakorlatai gyenge megértése és gyenge megvalósítása tapasztalható. Mielőtt rátérnénk arra a néhány okra, amiért az agilitás kudarcot vall(hat) a szervezetében, rá kell mutatnunk, hogy az agilitás nem egy „keretrendszer” vagy „módszertan”. Ez egy értékrendszer: a szoftverfejlesztés paradigmája, melyet egyformán meg kell érteni. Ez kicsit homályos megfogalmazás: mert a lényege az, hogy lehetővé teszi az Ön által a szervezetének megfelelőnek ítélt variációkat alkalmazni belőle. Gyakran összekeverik a SCRUM-mal (mely egy fejlesztési keretrendszer). Az agilitás nem írja elő a napi stand-upokat vagy sprinteket.
Miért nem tudjuk két nap alatt elindítani?
Sok mindent ki kell bontani ezzel a kijelentéssel az üzleti érdekeltek részéről. Amikor ezt a kijelentést bedobják, alapvető probléma van az Agile vagy a SCRUM gyakorlatok megértésében. Az agilitás nem a termékek véletlenszerű leszállítása! Ha valamit 3 hét alatt kell elkészíteni, akkor annak egyrészt igazodnia kell a sprintkiadásokhoz, másrészt pedig az üzleti célokhoz. Ha azt feltételezzük, hogy az agilis működés rugalmasságot ad az üzletnek, hogy bármikor elindíthassa a terméket, az feszült kapcsolatot teremt az érdekeltek és a szállító csapat között.
Amikor ilyen kijelentésekkel találkozunk, egyértelmű, hogy félreértik a metódust. Ne feledjük, az agilis módszereknek van egy folyamata. A kiáltvány azt diktálja, hogy az embereket a folyamatokkal szemben értékeljük, de ez nem jelenti azt, hogy a folyamat halott. Magyarázzuk el az érdekelt féleknek, hogy ez lehetséges (vagy ha nem lehetséges, akkor mikor lehetséges), azonban ez más dolgok eliminálása árán fog történni. Ha a fejlesztőcsapat éppen egy sprint közepén van, beszéljük meg a sprint lemondásának hatásait.
Tudni akarjuk, hogy mikor indíthatjuk el a terméket
Ez részben rajtunk múlik. A gyakorlott agilis szakemberek elmondják, hogy a SCRUM-ban az egyetlen jelentés az, amikor a napi és a sprint felülvizsgálati ülésekre sor kerül. Az agilitás új bevezetése (vagy az agilitásra való áttérés) esetében eltart egy ideig, amíg a csapat megérik az előrejelző szerepkörre. A PO felelős a csapat hatékony felhasználásáért: a megfelelő terjedelem adott időn belüli teljesítéséért. Az átláthatóság hiánya azonban akadályozza a vállalkozásokat abban, hogy erőforrásokat rendeljenek a kiadásokhoz. Ha például egy alkalmazást indítunk egy új régióban, akkor jelentős mennyiségű működési és marketing erőforrást kell felkészíteni: a hagyományos projektterv ezeket rögzíti, míg az agilis sprint-terv nem.
A termékmenedzserre hárul az átláthatóság biztosítása. Ne feledjük, a kiszámíthatóság empirikus adatokon keresztül jön létre: a csapatok múltbeli teljesítménye határozza meg a jövőbeli teljesíthetőséget. Ezt szem előtt tartva itt vannak a lépések: Értsük meg, hogy ez a projekt, mivel ez az első, meghatározza a csapatai sebességét és az érdekelt felek munkamódszerét. A hatókör ismeretében kérjünk becslést a fejlesztőcsapattól az indulás időpontjára vonatkozóan, megértve az ezzel kapcsolatos fenntartásokat (a hatókör nem változik, a technikai megértés ugyanaz marad). Biztosítsunk elegendő puffert a bevezetési dátum eléréséhez.
Az előző szervezetemben a vízesés módszerekkel indítottunk projekteket és működött
Ez egy tipikus probléma. Mindig akad valaki, aki vagy túlságosan követelőző („Az agilis csapatoknak akkor és azt kell teljesíteniük, amikor és amit az üzlet akar”), vagy egyenesen ellentmondásos („Az agilitás halott! Vízesést kellene használnunk. Vízeséssel jobban tudnánk tervezni”). Nehéz elhallgattatni a kritikusokat, különösen, ha vezető pozíciót töltenek be. Mielőtt belevágnánk, értsük meg a következőket: Elég érett-e a szervezetünk az agilis megoldások kezelésére? Ne feledjük, az agilitás először arról szól, hogy „hogyan gondolkodunk”, majd arról, hogy „mit csinálunk”. Sokkal nehezebb rávenni az embereket arra, hogy változtassanak a „gondolkodásmódjukon”, mint arra, hogy változtassanak azon, „amit csinálnak”. Van-e elegendő támogatás az agilis átalakításhoz a vezető érdekeltek körében?
A vezetői támogatás hiánya egy külön oka az agilitás kudarcának és egy külön cikket érdemelne. Ha mindkét kérdésre igen a válasz, akkor a következőket fogadhatjuk el: Foglalkozzunk a kritikusokkal, és értsük meg, hol vannak problémák a jelenlegi megvalósítással. Azonosítsuk a változtatási pontokat, melyek mindkét oldalon egyenlő esélyeket hoznak: lehet, hogy a SCRUM-csapatnak jobbá kell(ene) válnia a becslésben, míg az érdekelteknek abban kell(ene) javulniuk, hogy tudják, mit is akarnak.
(Kiemelt kép: Unsplash+)
