Agilis-e vagy? Bábeli zűrzavar az agilitás körül

Fodor Andrea

Már ott elakadsz, mit jelent az agilitás! Nézzünk néhány megközelítést:

Nemrég, az ITBUSINESS kiváló konferenciáján tartottam előadást arról, hogy mennyi értelmezése van az agilitásnak.

•  Felsővezetők részéről: az agilitás rugalmasságot, a szervezet gyors reagálását jelenti a piaci változásokra. Ezt szeretnék elérni, ezt az ígéretet hallják meg, amikor agilis transzformáció mellett döntenek. Vágyuk szerint ez úgy néz ki a gyakorlatban, hogy ha eddig A felé mentünk, de holnaptól B felé kellene fordulni, akkor ez a kinyilatkoztatás után röviddel megtörténik. És ezt úgy, hogy mindenki önálló, és tudja, merre van B, és mit kell hozzá tenni, hogy elérjük.
• Sokan az agilitás alatt egy projektleszállítási módszertant értenek, például a Scrum-ot. Klasszikus formájában egy 100%-ban a projekten dolgozó, üzleti és informatikai döntések meghozatalára felhatalmazott csapat rövid iterációkban szállít értékes funkciókat prioritási sorrendben.
• Nagyon nem mindegy, hogy egy-egy projekt agilis, netalántán a szállítói csapat a fejlesztést végzi agilis keretek között, vagy szervezeti szintű (ami általában csak az IT-t jelenti) agilis transzformáció zajlik. Ennek is vannak módszertani keretei: Spotify, SAFe, LeSs, Ezek mindegyike más működést, más szerepköröket definiál. Nagy nevű tanácsadó cégek ebben látják a fent említett felsővezetői elvárásnak való megfelelés kulcsát.
• HR-esek az ember oldaláról fogják meg a kérdést – egy felháborodott HR-es panaszkodott egyszer, hogy elment egy agilitásról szóló meetupra, és ott csak szoftverfejlesztésről beszélgettek, pedig az agilitás nem is erről szól. Ők egy olyan szervezeti kultúrát értenek agilitás mögött, ahol mindenki motivált, azaz önként és dalolva fogja a talicska végét, és lelkesen tolja a vezetőség által meghatározott irányba. Tanulnak a hibáikból, folyamatosan fejlődnek, és közösen együttműködve repítik elképzelhetetlen magasságba a szervezetet.
• Én üzleti specifikációkkal foglalkozom, bonyolult és erősen szabályozott üzleti folyamatok informatikai támogatását specifikáltam vagy projektvezettem szakmai pályám során, ezért én az informatika terméktervezés oldaláról szoktam vizsgálni az agilitást. Az én szemüvegemen keresztül az agilitás az jelenti, hogy az informatikai fejlesztésekben a lehető legrövidebb idő alatt a lehető legnagyobb üzleti értéket állítjuk elő. Megszabadulunk az üzleti értéket nem jelentő feleslegektől, mindent funkcióról, kódrészletről tudjuk, hogy azt kinek és miért fontos, milyen üzleti értéket hordoz (ezt user storyban foglaljuk össze), és nem fordítunk energiát olyan részletekre, ami senkinek nem fontos. Nyilván ez is egy csak egy szelet….

Agilis vagy hibrid?

Miért van az, hogy a nagyvállalatok – kevés kivétellel – az agilitást sem lenyelni, sem kiköpni nem tudják? Hogy senkinek az elvárása nem teljesül maradéktalanul? Hogy bár nemes a cél, de a megvalósítás döcög, és sokszor nem is a cél irányába mutat a haladás?

A mellékelt ábrával majdnem minden agilis tréningen találkozhatunk. Azt hivatott szemléltetni, hogy a klasszikus waterfall megközelítéssel szemben, amikor a termék üzleti előnyeit csak a leszállítás után lehet realizálni (akkor tudunk eljutni A-ból B-be, ha kész az autó), az agilis termékfejlesztés során a termék üzleti eredményeit jóval korábban (már a gördeszka piacra dobásakor) élvezhetjük.

Ezzel tapasztalatot gyűjthetünk, és tanulhatunk abból, hogyan fogadja a piac az ötletünket. A visszajelzések alapján módosíthatunk a koncepción, simán kiderülhet, hogy nem is autóra, hanem kisrepülőgépre van szükség.

Ez a filozófia életmentő lehet startupok esetén, akiknek a leggyakoribb problémája, hogy túl sokáig dédelgetik az ötletüket, mielőtt piacra dobnák, és túl sok pénzt-időt-energiát invesztálnak valamibe, amit esetleg a piac nem úgy fogad, mint azt eltervezték.
Jó lehet innovációs projektek esetén, amikor egy cég – akár nagyvállalat – új terméket szeretne piacra vinni. Bár ez esetben már rendelkezésre állnak az erőforrások egy rendes piackutatás, vagy fókuszcsoport alkalmazására, amivel konkrét ügyfélkövetelmények és vélemények gyűjthetők, és ez valószínű olcsóbb, mint próbálkozni a különböző megoldásokkal.

Nem jó, de sajnos néha elkerülhetetlen az az eset, amikor IT megoldásszállítók – és ne felejtsük el, hogy az agilis kiáltvány maga ilyen cégektől származik – az ügyféltől zavaros, nem egyértelmű, hiányos követelményeket kapnak, és a stakeholderek nem elérhetők egyeztetésre. Ilyenkor valóban nincs más választásuk, mint minél előbb szállítani valamit, amiről az ügyfél elmondhatja a véleményét. De ettől még a megrendelő nem realizálhatja a fejlesztés üzleti eredményét, csak egy „prototípus”-nak nevezett követelménygyűjtési technikát alkalmaznak, hogy megértsék azt, hogy mire van az ügyfélnek valóban szüksége. De ennél is jobb megoldás, ha felmérjük és elemezzük a követelményeket, egy olyan megoldást kialakítva, amibe beépítettük az üzleti követelményeket, a vonatkozó üzleti és jogszabályokat, meg tudunk felelni a nem funkcionális követelményeknek, és le tudunk kezelni minden előforduló üzleti eseményt.

Mi a helyzet az agilitással megrendelői oldalon?

Ahol a projektek 99%-ánál van előre meghatározott leszállítandó? A megrendelőnél már működik egy autóbusz, csak egy szebbet, nagyobbat, olcsóbban üzemeltethetőt, kényelmesebbet szeretnének? Az ügyfelek mennyire lennének elégedettek, ha egy gördeszkát kapnának? Ha tetszik, ha nem, ilyenkor hibrid megoldásokba kényszerülünk bele.

Hibrid megoldás kell:

• ha van konkrét leszállítandó és mellette költség és/vagy időkeret
• sok a stakeholder, akiknek a követelményeit figyelembe kell venni, és az információ elérhető
• Sok az olyan adottság, amihez alkalmazkodni kell (sok üzleti szabálynak, vagy jogszabálynak kell megfelelni)
• Minimum Viable Product kialakításánál
• Komplex, sok függőséggel járó projekt esetén.

Ez persze csak akkor jelent problémát, ha ez nem tudatosul, és a tiszta agilis elemeket szeretnénk erőltetni. Tudomásul kell venni, hogy hibrid projektnél:

• kell előzetes tervezés, specifikáció valamilyen szintig (hogy milyen szintig, azt a kialakítandó termék komplexitása, illetve a leszállításban részt vevő csapatok/szakterületek száma és a függőségek mértéke határozza meg).
• definiálni szükséges, hogy üzletileg hogyan működjön az adott megoldás – ehhez az információt (ha rendelkezésre áll) össze kell gyűjteni és elemezni kell (üzleti elemzés), és be kell építeni a megoldásba.
• a változásokat ugyanúgy kontrolláltan kell kezelni, mint a klasszikus projekteknél (megnézni, hogy milyen már elvégzett munkára van hatással, mit kell visszamenőleg megváltoztatni)
• e miatt a követelményeket és a függőségeket dokumentálni kell
• sokszor kell a megoldásban kompromisszumokat kötni, üzleti döntéseket meghozni, kockázatot vállalni. Ezek a döntések sok esetben több üzleti és szakterületet érintenek, és nem, a csapat soha nem lesz felhatalmazva ilyen döntések meghozatalára (a megoldásra vonatkozó döntések meghozatalára talán), és ez lassítani fogja a leszállítási folyamatot.
• az üzleti érték csak akkor realizálható, ha end-to-end minden eleme elkészült (a felületen lévő funkció mögötti üzleti logika működik, a tranzakció könyvelésre került, a díj elszámolódott, a számla elkészült, a vezetői kimutatásokban jól megjelenik). Ezt csak akkor lehet felülírni, ha az a döntés tudatos, vállalja a következményeket és átmeneti.

Van megoldás?

Ennek a problémának az áthidalására dolgoztuk ki követelménymenedzsment módszertanunkat, amelyben összefésültük, ezért kombinálhatóvá tettük a terméktervezést. Business Analyst képzéseinken is oktatott módszertanunk lényege:

• agilis szemléletre alapoz
• design thinking elemeire épít
• alkalmazott módszertantól független
• kombinálható is, ha több, eltérő módszertannal működő projekt is érintett
• minden szervezeti működésbe beépíthető
• biztosítja az üzleti célok elérését.

Business analyst képzéseinket itt találod >>>

IT beszállítóknak ezt az üzleti elemző képzést ajánljuk >>>