Kísérletképpen lefordítottuk Craig Larman egy szerintünk fontos, az agilitáshoz kapcsolódó angol nyelvű cikkét. Bár az IT széles körben elfogadott nyelve az angol, természetesen vannak olyan szervezetek, ahol nem természetes a készségszintű angoltudás (például mert jellemzően hazai vagy akár németajkú ügyfélkörrel rendelkeznek), ezért lehet érték abban, ha anyanyelvünkön is elérhetőek a nemzetközi szakirodalom elemei. Amennyiben hasznosnak találjátok a fordítást és szeretnétek, ha ez szokásunkká válna, pozitív kommenttel jelezzétek. :) Az eredeti cikk itt olvasható.

Less Agile vagy LeSS Agile?
(szójáték - a less jelentése kevesebb, míg a LeSS a Large Scale Scrum módszertan nevének rövidítése)

Az embereknek elment az eszük?

Nemrég találkoztam egy olyan agilis és Scrum definícióval, mely szerint a cél, hogy “...a szervezet gyorsuljon, javuljon a tervezhetőség, mindez a létező csapatok optimalizálása mellett”. Barátom, ez aztán lehangoló volt. Vajon az emberek elfelejtették, hogy miért pont az “agilis” szóra esett a választás?

Miért pont “agilis”?

Egyetértesz a következő állítással? Az agilis célja, hogy javítsa a hatékonyságot, a tervezhetőséget, a produktivitást és teljesítse a projekttervet.

Ha igen, nem akarlak megbántani, de nem vagy tisztában azzal, hogy miért is nevezik agilisnak, hogy mi a célja, és hogy mi az oka annak, hogy a Scrumot és a kapcsolódó megközelítéseket agilis módszertanoknak nevezik. És ez rendben is van így. Azért vagyunk itt, hogy segítsünk. ;)

Kezdjük egy kis történelemmel, hogy megértsük, miért az “agilis” nevet választották: Az 1990-es években a “light” framework-ök egy családja kezdett népszerűvé válni, beleértve a Scrumot, az XP-t, a DSDM-et, a Crystalt és az Adaptive Software Developmentet. Ezekről a rendszerekről 2000 végén Bob Martin (“Uncle Bob”) szeretett volna egy találkozót szervezni a hasonlóan gondolkodó embereknek. Végül 2001 februárjában megtartották a Snowbird találkozót, melyen jelen volt Ken Schwaber és Jeff Sutherland is (a Scrum megalkotói).

Most jön a kulcspont: A Snowbird találkozó kezdetén a csoport szeretett volna egy nevet választani, amivel körül tudják írni ezeknek a frameworköknek a fő célját. Két “pályázó” közül választottak: adaptív (Jim Highsmith javaslatára) és agilis (Mike Beedle ötlete). Kérlek, gondosan figyeld meg a szóválasztást: mindkét kifejezés magában hordozza a flexibilitást. Martin Fowlert idézve, aki szintén jelen volt az eseményen:

“Pár nevet fontolóra vettünk, és végül az “agilis” szóban állapodtunk meg, mivel úgy éreztük, ez kifejezi az alkalmazkodóképességet és a változásra való reagálást, mely úgy éreztük nagyon fontos a mi megközelítésünkből.”

Agilis egyenlő agilitás

2001-ben, amikor az “agilis” szó kiválasztásra került, Kent Beck XP Explained című alkotása volt a sikerkönyv. Érdemes megfigyelni az alcímet: Embrace Change (“Fogadd be a változást”). Kent egyik kulcs témája az XP motiválásában az volt, hogy tanuláson és alkalmazkodáson keresztül találjon megoldásokat, és ahhoz, hogy ez a megközelítés hatékony legyen, szükséges a változás költségének csökkentése.

Röviden, az agilis agilitást jelent. A Scrum - egy agilis framework - mindenek előtt  az agilitással egyenlő. Nem a hatékonysággal, a tervezhetőséggel, a produktivitással, sem azzal, hogy teljesüljön a projektterv. Ezt még inkább kihangsúlyozták az agilis értékekben és alapelvekben, melyeket a csoport alkotott meg:

“A megrendelővel történő együttműködést a szerződéses egyeztetéssel szemben.”
“A változás iránti készséget a tervek szolgai követésével szemben.”
“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.”

A Scaling Lean & Agile Development: Thinking & Organizational Tools for Large-Scale Scrum című könyvben, mely az első LeSS (Large-Scale Scrum) könyv volt, az egyik gondolkodási eszközökről szóló fejezet címe “Légy agilis”; a következőket tartalmazza:

Az “agilis” nem egy gyakorlat, hanem egy tulajdonsága a szervezetnek és az embereknek, hogy adaptívak, reszponzívak, folyamatosan tanulni és fejlődni képesek - hogy agilisak. … Az agilis nem jelent gyorsabb szállítást, nem jelent kevesebb hibát vagy magasabb minőséget. Az agilis nem jelent nagyobb produktivitást sem. Az agilis azt jelenti: agilis - a képességet, hogy gyorsan és könnyeden lehet mozogni, fürgének és alkalmazkodónak lenni. Azért, hogy befogadjuk a változást és a változás mestereivé váljunk - hogy az alkalmazkodáson keresztül versenyezzünk a konkurenciával, úgy, hogy képesek vagyunk a változásra, gyorsabban és olcsóbban, mint a versenytársak.

Valószínűleg egy olyan agilis módszertan, mint a Scrum, gyorsabb szállítást és magasabb minőséget eredményez, de létfontosságú, hogy az üzleti és műszaki vezetők tisztában legyenek azzal, hogy az agilis módszertanok “raison d’être”-je...az agilitás.

Érték és agilitás

Mi a helyzet a “legnagyobb érték korai szállításával”? Hát nem ez a célja az agilis megközelítéseknek és a Scrumnak? Nos, igen, de létfontosságú megérteni, hogy az “agilis” kulcsüzenete az, hogy az érték szállításához vezető út egyre inkább - a mai felgyorsult, gyakran változó, erősen versenyképes környezetben - a szervezeti alkalmazkodóképesség (irányváltoztatás) lesz, olcsón és egyszerűen, tanuláson és visszajelzésen alapulva, semmint előre tervezéssel és “a terv követésével”.

Szeretem azt mondani, hogy az agilis módszertanok - beleértve a Scrumot - célja, hogy sikeres megoldásokat találjon azáltal, hogy képes…gyorsan irányt váltani.

Az agilis és a Scrum szíve nem a “projektterv megfelelő végrehajtása”. Nem a “sebesség, a hatékonyság, a tervezhetőség”, stb. a lényeg. Azok, akik ezt az üzenetet terjesztik, elfelejtették az agilis történet lényegét.
(Fordítói megjegyzés: ha megnézitek cégünk honlapját, mi is hatékonyságról, tervezhetőségről, stb. beszélünk. Miért postolunk akkor a személyes blogunkra egy olyan cikket, ami szerint ez kimondottan hiba? Ekkora öngólt lőttünk volna? Ellenkezőleg. Fontos üzenetnek tekintjük, hogy az agilitás fő célja maga az agilitás, abban az értelemben, ahogyan a cikk is magyarázza. Ugyanakkor tény, hogy a döntéshozó réteg jelentős részét ez a cél még nem mozgatja meg eléggé. Hisszük, hogy nem baj, ha egy várható “mellékhatás” miatt indul el egy szervezet agilis irányba, és nekünk, tanácsadóknak feladatunk menetközben megmutatni a módszertan és a filozófia valódi célját és értékét.)

Less Agile vagy LeSS Agile: Leskálázás LeSS-szel

Ahogy Bas Vodde, barátom és egyben a LeSS társalkotója, úgy az én fókuszomban is az áll, hogy segítsem a nagyobb termékek csapatait agilissá válni, majd sikeres megoldásokat találni és szállítani azáltal, hogy gyorsan tudunk irányt váltani skálázott környezetben is.
A nagy, hagyományos fejlesztőcsapat gyakran akadályozza az agilitást és a flexibilitást a szervezeti felépítésük miatt; strukturálisan kevésbé agilisak. Ezért az első LeSS könyvben (2008), ezt írtuk:

“Fontos, hogy megértsük, a szervezeti agilitás nem érhető el a fejlesztőcsapat elszigetelésével -- ez a rendszer kihívása a szervezeti átszervezésre. Különösen akkor, ha a LeSS-t egy többezer fős R&D osztályon szeretnéd megvalósítani, ahol minden egyes termék csapata 200 vagy 700 főből áll, 2 vagy 5 site-on szétszórva. Ha egy mérnök csapatnak megvan a technikai kapacitása arra, hogy gyorsan alkalmazkodjon vagy változzon, de a követelménymenedzsment, a jogi gyakorlatok, a termékmenedzsment, a HR elvek, a helyi stratégiák és a fejlesztési folyamatok mind a merevséget, az eredeti terveknek és a status quo-nak való megfelelést, a lassú gyakorlatokat hangsúlyozzák, akkor ott hogyan lehet igazi agilitás?”

A “változás olcsóvá tételének” lényege különösen releváns a skálázásban, mivel a large-scale csapatok gyakran állandósult szervezeti felépítéssel rendelkeznek, és olyan folyamatokkal, amik “a változást költségessé teszik”. Tehát ami a sikeresen skálázó Scrumban történik az nem más, mint azon szervezeti elemek eltávolítása, amik megbénítják az irányváltoztatás könnyű és olcsó megvalósulását. Mi lehet példa ezekre az elemekre, melyek meggátolják az “egyszerű és olcsó változást”? Csapatok, akik csak egy dologhoz értenek, projekt mérföldkövek, a hagyományos program/projektmenedzsment rendszer, specialista munkatársak, magas szintű WIP-ek, csapatok közötti átadás, és a többi.

Tehát a LeSS nem igazán arról szól, hogy lehetőséget biztosítsunk egy létező nagy csapat számára, hogy “Scrumot csináljon nagyban”. Sokkal inkább, a LeSS a szervezet leskálázásáról szól, és egy olyan design megalkotásáról, ami szisztematikusan lehetővé teszi az agilitás skálázást, egyszerű elemekkel, hogy LeSS Agile legyen.

Ha többet szeretnél tudni a LeSS-ről és a szervezetek leskálázásáról az igazi agilisért, nézd meg a LeSS.works-öt.