Havi mustra az agilis transzformációról

2019. március 04.

Köszöntöm az Olvasót! Az előző havi mustrában [1] az „Agilis gyakorlati útmutatóról” szóló recenziót kiemelkedően sokan olvasták el, vélhetően a hazánkban jelenleg is több szervezetnél folyó „agilis transzformáció” (átalakulás) miatt. Egy szervezet gyökeres átalakítása mindig felkavarja az állóvizet, ezért most a szokásoktól eltérően visszatérek erre a témára.

Az „agilis transzformáció” nem projektmenedzsment tárgyú felvetés, ez valójában a szervezetfejlesztés (organizational development) területéhez tartozik. Amíg zajlik egy ilyen átalakítás folyamata, az persze projektként fogható fel és erre szakaszra használhatjuk a szokásos projektmenedzsment eszközöket.

Több nagy tanácsadó cég is ajánl olyan szolgáltatásokat, amelyek ahhoz segítik hozzá (az azért fizető) ügyfeleiket, hogy bátrabban léphessenek az agilis transzformáció rögös útjára. Ezek a cégek a honlapjukon figyelemfelkeltő írásokkal próbálják a szolgáltatásaik jövendőbeli vevőit becsalogatni [2] [3].

Ezek az írások rendszerint a szoftverfejlesztő cégek gyakorlatából indulnak ki [4] [5], amikor a változásokhoz való gyorsabb alkalmazkodás képességét csillantják fel más (például pénzügyi vagy telekommunikációs) iparágban működő vállalatok számára. Érdemes ezért kiindulásképpen a szoftverfejlesztő cégek gyakorlatát megvizsgálni. Gyakran hivatkoznak Spotify példájára, amiről elérhető egy 25 perces videó a YouTube-on [6], érdemes rászánni az időt. Mint látni fogják, a Spotify-nál lényegében egy mátrix-szervezetet építettek fel, ahol az egyik dimenzióban megjelenő, a jól elkülöníthető tartalmi egységek fejlesztéséért (programozásával) teljes mértékben felelős, kis létszámú autonóm „osztagokat” (squad-ok) találunk. Az osztagoknak azt mondják meg, hogy mit várnak el tőlük, viszont többé-kevésbé szabad kezük van abban, hogy ezt hogyan érik el. A logikailag összetartozó fejlesztéseket végző osztagok egy törzshöz („tribe”) tartoznak. A mátrixszervezet másik dimenziója a munkatársak kompetenciáján alapul, itt a nagyjából hasonló munkakörben dolgozókat tagozatba („chapter”) tömörítik. A munkavállalók közvetlen munkahelyi felettesének a tagozat vezetője („chapter lead”) felel meg (az osztagnak is van vezetője, a „squad lead”; ebben az értelemben hasonlít ez egy projektalapú szervezetre). A törzsek között informális kapcsolatok intézményesítésére pedig a szintén kompetencia alapján szerveződő céhek („guild”) hivatottak. A céhekben a tagság önkéntes.

Azoknak, akik sajnálják az időt a Spotify-videó végig nézésére, elárulok két titkot, hogy vajon miért lehetett eredményes a fenti munkaszervezési mód. Az egyik trükk az, hogy a Spotify-t, mint szoftverterméket olyan módon valósítják meg, hogy annak egyes részei ne nagyon függjenek a többi részektől (ez az ún. „loosely coupled architecture”). Többek között ez az, ami lehetővé teszi azt, hogy az osztagok a lehetőségekhez képest függetlenül, párhuzamosan dolgozzanak. A másik nagy titok, amire a videóban (és az irodalomban is) gyakran hivatkoznak, az a befogadó és támogató (szervezeti) kultúra, melynek része többek között a hibák elfogadása és az azokból történő tanulás hangsúlyozása. A befogadó kultúra teszi lehetővé, hogy egyszerre legyenek a dolgozók motiváltak és fegyelmezettek.

Azért fontos a fenti két trükk (avagy feltétel) megértése, mert ha olyan szervezetben próbálják mechanikusan, pusztán egy mátrixszervezet egységeiben (egység, törzs, cég) gondolkozva az agilis transzformációt végig vinni, ahol ezek nem teljesülnek, ott az eredmény kétséges. (lásd a múlt havi mustrában hivatkozott kritikai észrevételeket [7]). Ahhoz, hogy valaki értelmes „agilis átalakítási” javaslatokkal álljon elő, ismernie kellene az átalakítandó szervezet értékteremtő folyamatait, pontosabban azokat a kötöttségeket, ami az ott használt technológia természetéből adódnak. Például nekem egy könyvelésre szakosodott vállalkozás agilis transzformációja nehezen képzelhető el, de az is igaz, hogy még nem próbálkoztam ilyesmivel. Ki tudja, még az is lehet, hogy sikerülne.

A befogadó kultúra szemszögéből vizsgálva, egy, a hibázást nem toleráló környezet önmagában megakadályozhat egy eredményes agilis átalakulást, míg ezzel szemben, ahogy a Spotify-video vége felé állítják, „az egészséges kultúra kikúrálja a beteg folyamatot”, „healthy culture heals broken process” (a videóban 24:10 után).

Egy agilis átalakítás további Achilles-sarka a szervezet mérete (a méret a lényeg). Az agilis szoftverfejlesztés kicsi, összeszokott csapatokban működik jól, a nagy (esetleg földrajzilag elosztott) szervezetekben problémás lehet egy ilyen működési modell használata. A szoftverfejlesztés világában erre a helyzetre is vannak (egyedi) megoldási javaslatok (ilyen például a Scaled Agile Framework [8], vagy a Large-Scale Scrum (LeSS) keretrendszer [9]). Ezekben olyan nehéz kérdésekkel is foglalkoznak, mint például a külső (más jogi személy által foglalkoztatott) személyek bevonása az agilis működési modellbe, de ezzel aztán el is vesztik az eredeti faékegyszerű megközelítés hamvas báját.

Gyakran emlegetett példája az agilis transzformációnak az ING Bank esete, amiről nekem csak a bank által közzétett népszerűsítő videókból [10] [11] [12] [13] vannak ismereteim. Ezekben a videókban az érintettség miatt nem könnyű elválasztani egymástól a kiszínezett és a tényleges valóságot. Az viszont kitűnik belőlük, hogy az ING Bank esetében is domináns volt a szoftverfejlesztés szerepe (lásd erről a hatásról a múlt havi mustrát [14] is). Aki vezetőként más, a szoftverfejlesztéstől nagyon eltérő ágazatban dolgozik, azt azért óvatosságra inteném az agilis transzformációval kapcsolatban.

Egy újszülöttnek minden vicc új, az öregember pedig szinte mindenre csak biccent, hogy ilyet is láttam már. Amit ma agilis transzformációnak neveznek, annak sem a formai, sem a tartalmi intézkedései önmagában nem tekinthetők újnak, az összeállításuk viszont újszerű. Olyan ez, mint amikor egy mixer új koktélt kever ki a jól ismert italokból. Az alkotórészek ismertek, ezért az új kotyvaléknak lehetnek előre látható nem kívánatos mellékhatásai [15]. Az okos, óvatos és körültekintő vezetőt a helyes jövőkép és a jelenlegi helyzet megbízható ismerete vezesse és ne a dogmatikus hit, amikor arról dönt, hogy rálépjen-e az agilis transzformáció útjára - az idősebb olvasók emlékezhetnek még az üzleti folyamatok újjászervezése, avagy Business Process Re-engineering tündöklésére és bukására.

Klimkó Gábor

Hivatkozások:

[1] lásd https://www.pmsz.hu/hirek-aktualitasok/havi-mustra/havi-mustra-a-magyarul-megjelent-agilis-gyakorlati-utmutatorol

[2] Aghina, de Smet és Weerda (2016) Agility: It Rhymes with Stability. McKinsey Quarterly, Issue 1, p58-69. https://www.mckinsey.com/business-functions/organization/our-insights/agility-it-rhymes-with-stability

[3] Boston Consulting Group, https://www.bcg.com/digital-bcg/agile/default.aspx

[4] Wilmott, P. (2015) Want to become agile? Learn from your IT team, https://www.mckinsey.com/business-functions/digital-mckinsey/our-insights/want-to-become-agile-learn-from-your-it-team

[5] Applying Agile to Software Development and Beyond, https://www.bcg.com/digital-bcg/agile/software-agile.aspx

[6] Spotify Engineering Culture Full Video (Agile Enterprise Transition with Scrum and Kanban), https://www.youtube.com/watch?v=R2o-Xm3UVjs

[7] Tanács, L.(2019), Az Öreg Király és az Agilis Transzformáció, https://www.youtube.com/watch?v=o5sI6eGQWqQ

[8] lásd https://www.scaledagileframework.com/

[9] lásd https://less.works/

[10] lásd 360° Agile way of working by ING (ENG) https://www.youtube.com/watch?v=cxGXQxsaPy8