Közérthetően és őszintén az agilis módszertanokról

Agile blog

Kell-e nekünk Agile?

2016. június 08. - Bodó Árpád Zsolt, Margetin István

Ismét egy korábbi postunk kommentjére szeretnénk bővebben reagálni, ezúttal a “Helytelen ügyfélviselkedés?" címűre. Érdekes és komplex kommentet kaptunk tnsnames.ora nevű olvasónktól, köszönjük. Ha valamelyik pontot félreértettük, előre is elnézést kérünk! Nézzük a felvetéseket:

"Én fordítva szeretek ülni a lovon. Tervezés során előre várnám el, hogy megmondható legyen milyen esélye van az agilis módszertannak a vázolt "kiküszöbölésekre" és "feltétel-megteremtésekre".  (Szerk.: azok kedvéért, akik most nem olvasták újra az eredeti postot: a “kiküszöbölés” az általunk rossz változásnak nevezet, meggondolatlanságból, felkészületlenségből, kommunikációs hibából fakadó változások kiküszöbölésére vonatkozik.)"

Csapaton belül kétféleképp értelmeztük ezt a gondolatot, reagálunk mindkét értelmezésre.

Ha arra gondolt a szerző, hogy mielőtt belefognánk egy agilis módszertan bevezetésnek, illik tudni, hogy van-e az egésznek értelme, mélyen egyetértünk. Ezért is van az, hogy nálunk minden bevezetési projekt nulladik lépése egy felmérés, melynek célja megismerni a kulcsszereplőket, a helyzetet, a terméket, a feltételeket, a körülményeket… És aminek a végén többek között egy bináris választ adunk arra a kérdésre: érdemes-e ebben a környezetben agilis bevezetést végezni. A bináris válasz nagyon sokféle lehet :) A határozott igen a legritkább, az “igen, ha ezt és ezt a feltételt meg tudjuk változtatni” pedig a leggyakoribb. Hozzátartozik, hogy tudunk és szoktunk is nemet mondani;  egy sikertelen bevezetés senkinek sem jó.

A másik értelmezésünk az, hogy a kommentelő a módszertantól várja, hogy kiküszöböljön emberi hibákat. Erre sajnos nem tudunk ilyen pozitív választ adni: a módszertan erre alkalmatlan. Annyit lehet elvárni tőle, hogy megteremti a szükséges feltételeket, megadja a kereteket amik között nagyon jól lehet csinálni; de az emberi faktort csak emberek tudják kezelni. Ezért is nagyon fontos, hogy a sikeres bevezetés feltétele a management aktív támogatása és részvétele is, és természetesen sok múlik a kulcsszereplőkön, a Product Owneren és a Scrum Masteren is.

"Azt gondolom ugyanis, hogy tapasztalat alapján ez előre tudható, ez a felmérés és végiggondolás előre elvégezhető. Nem pedig trendnek és gazdasági szorításnak engedve az agilis módszertanba belecsobbanva "csak" a legjobbat hozzuk ki a fejlesztési szituációból."

Egyetértünk, a felmérés és a végiggondolás előre elvégezhető. Az agilis módszertant nem a trendnek és gazdasági szorításnak engedve érdemes bevezetni, hanem pusztán a mai üzleti körülményekhez való alkalmazkodás és a túlélés érdekében. És ez egy nagyon fontos szempont, amikor azon gondolkodunk, kell-e nekünk agilis: milyen környezetben élünk. Ha valóban előre tervezhető az életünk, az üzleti környezetünk, a termékünk, akkor nincs erre szükség.

Az agilis célja a változásokra való reagálás. És a legtöbb üzleti területen ezt nem lehet megúszni. Mi változik? Minden. Például:

  • Változnak a hardware eszközök, amelyekre fejlesztünk.
  • Változnak a software eszközök, platformok, amelyekre fejlesztünk.
  • Változnak a software eszközös, amelyekkel fejlesztünk.
  • Változnak a külső komponensek.
  • Változnak az üzleti igények, hiszen az ügyfelek is folyamatosan tanulnak. És persze azért is változnak, mert az ügyfél / vevő / felhasználó meggondolja magát. Nem azért mert gonosz, nem azért mert buta, azért mert ember. És mint ember, amikor már látunk valamit, sokkal könnyebb kitalálni, mit is szeretnénk, mint amikor még csak egy üres papír felett töprengünk.
  • Változik az üzleti környezet. Találkoztunk olyan nagy, sikeres, kényelmes céggel, ami azért volt kénytelen elindulni agilis irányba, mert hirtelen rengeteg apró, gyors, ügyes startup jelent meg a piacukon, és felismerték, hogy a szokásos másfél éves release ciklussal nagyon hamar elmegy mellettük az élet…

Ha a fenti változások bármelyike érint bennünket, akkor határozottan jó döntés agilis irányba elmozdulni. És valóban, akkor az a cél, hogy a legjobbat hozzuk ki abból, amink van. A “csak” szócskát viszont nem érezzük itt jogosnak. Van jobb, mint a lehető legjobbat kihozni egy olyan helyzetből, ami jórészt az irányításunkon kívül van?

"A másik óriási gond lehet a gombhoz a kabát típusú probléma. Mind a kiküszöbölés, mind feltétel-megteremtés komoly szervezetfejlesztési vonzatot is takarhat, ráadásul megrendelő oldalon. Belegondolva GE-s múltamba, tudok kevéssé optimista lenni."

A fenti blokkban leírtuk, mikor érdemes agilis irányba menni. Fontos ugyanakkor kiemelni, hogy az, hogy érdemes, még nem jelenti azt, hogy a szervezet is felkészült rá. Teljesen egyetértünk a hozzászólással: igen, az agilis módszertan bevezetése kihat a szervezetre a fejlesztési folyamatokon és a fejlesztési csapaton kívül is. A sikeres bevezetés feltétele, hogy a management, a business és a delivery mind mellé álljon és részt vegyen benne. Enélkül nem megy.

Érdemes megfigyelni például, hogyan beszélnek egy szervezetben az agilitásról. Ahol ez egy process, vagy egy “way of working”, ott a siker esélye sokkal kisebb, mint ahol ez egy “működési mód”, egy “gondolkodásmód”.

Köszönjük a provokatív kommentet; ahogy tréningen is szoktuk mondani a résztvevőknek: a jóindulatú szkepticizmus hasznos, mert az ilyen hozzáállással feltett kérdések nagyon sokat segíthetnek a helyes megértésben.

Motiváció 3.0

A “Csapatmorál az agilitásban” postunkra érkezett kommentben kaptunk egy kritikát, amiért a morál tárgyalásánál megemlítettük a fizetésemelés kérdését.

A kritika jogos, valóban nem a pénzről szól a motiválás, mi mégis szándékosan utaltunk rá, ugyanis az a tapasztalatunk, hogy nem lehet morál és motiváció témában figyelmen kívül hagyni az anyagi kérdéseket. Egyrészt azért, mert ma is sokan gondolkodnak úgy, hogy ha motiválni kell, adjunk pénzt az embernek, másrészt azért, mert akik pedig felismerték az egyéb motivátorokat, abba a csapdába eshetnek, hogy nem veszik elég komolyan a pénz kérdését. Ahogy a Motiváció 3.0 elméletéről híres Dan Pink mondja, a megfejtés: “take the problem of money off the table”. Természetesen amíg azon kell aggódnia a dolgozónak, miből fogja etetni a gyermekeit és tudja-e fizetni a lakáshitelét, akármennyire álomszerű minden más körülmény, ő nem lesz motivált. Meg kell találni a megfelelő szintet, és utána anyagi jutalmazás helyett más motivátorokat keresni. Nem is motivátorok ezek - bizonyos helyzetekben nem lehet kívülről motiválni -, hanem csak feltételek, amiket ha megteremtünk, akkor beindulhat a belső motiváció.

A belső és külső motiváció közötti különbségről, a belső motivációhoz szükséges feltételekről és a mögöttes kutatásról az alábbi videót ajánljuk figyelmetekbe:

Definition of Done vs Release Criteria

Fontos üzenet minden tréningünkön, hogy a módszertan testreszabását kerüljük, mert nagyon veszélyes tevékenység. Az üzenet mögött az a megfigyelés áll, hogy a leggyakoribb oka a testreszabásnak az, hogy a szervezetben van egy (vagy több) rosszul működő folyamat, és ezek megváltoztatása helyett próbáljuk ezekre faragni a módszertant. Az eredmény ilyenkor egész könnyen megjósolható: természetesen bukás lesz a vége. És természetesen ilyenkor a módszertant szokták okolni a bukásért…

A fenti fontos figyelmeztetés ellenére el kell ismerni, hogy igenis vannak olyan helyzetek, amikor muszáj testreszabni a módszertant. Ilyen eset, amikor szükségessé válik a release criteria bevezetése.

Ahogy korábban már kifejtettük a Definition of Done-ról szóló bejegyzésben, a D.o.D. azon közös feltételek gyűjteménye, amit minden egyes feladatnak teljesíteni kell a készség kimondásához. Lefordítva, a D.o.D. biztosítja a Scrum azon célját, hogy a sprint végén valóban “potentially shippable product increment”-ünk legyen, tehát valóban csak üzleti kérdés legyen, hogy tényleg kiadjuk-e a terméket. Technikailag kiadásra késznek kell lennie.

No ez nem megy mindig. Elképzelhető, hogy van a kiadásnak olyan feltétele, ami pénzben vagy időben túl drága ahhoz, hogy minden sprintben végrehajtsuk. Bizonyos területeken például a kiadás feltétele lehet egy független hatóság általi jóváhagyás, vagy különleges környezeti tesztek futtatása (hőkamrák, klímakamrák, fénytesztek, stb.). Ez utóbbi természetesen sokkal gyakoribb olyan környezetben, ahol hardware fejlesztés is történik.
Mivel tehát ezek az ellenőrzések drágák és sokáig tartanak, nem férnek bele a sprintbe. Így a definition of done részének sem tekinthetjük őket. Kell tehát egy lista, ahol azokat a feladatokat gyűjtjük, amiket a kiadás előtt muszáj végrehajtani, de nem tudjuk backlogelemenként, a sprint során elvégezni. Ez a lista lesz a Release criteria.

Szerencsés esetben ez a lista nem létezik. Ugyanis ha van, akkor sérült az a cél, hogy minden sprint végén kiadható termékünk legyen. Ilyenkor legyen legalább az cél, hogy minden sprint végén, kontrollált környezetben demozható termékünk legyen, hogy a feedback lehetősége továbbra is megmaradjon.
A release criteria létének másik veszélye, hogy a sprinten kívülre szoruló feladatok, tesztek, ellenőrzések rámutathatnak hibákra, amik így a folyamat késői pontján derülnek ki, tehát drágák lehetnek. (Emlékeztetőül: a scrum egyik nagy ereje, hogy a tesztelést nem külön fázisnak, hanem a fejlesztés részének tekinti, így gyors a visszajelzés tesztelés és fejlesztés között, és mivel rövid a feedback loop, a hamar felfedezett hibákat gyorsan és olcsón lehet javítani.)
Ezek miatt tehát törekedjünk arra, hogy:

  • ne legyen Release criteriánk
  • ha van, legyen a lehető legrövidebb
  • folyamatosan törekedjünk arra, hogy a release criteria elemeit bontsuk, és minél nagyobb részben mozgassuk át ezeket a definition of done-ba.

Mit gondoltok?

Lassan fél éve, hogy belekezdtünk ennek a blognak az írásába, és heti-kétheti rendszerességgel jelentkezünk friss bejegyzésekkel az agilis módszertanokról. Fontos nekünk, hogy mit gondoltok a blogról, az írásainkról, ezért kérünk benneteket, hogy szánjatok egy fél percet az alábbi rövid kérdőív megválaszolására! Köszönjük!

Create your own user feedback survey

No partial credit

Fontos, de fájdalmas kérdés: mi legyen a sprint végén a “majdnem” kész feladatokkal? Valójában ez két kérdés: automatikusan bekerüljön-e a következő sprint backlogjába, és hogyan könyveljük a pontokat?

Az első kérdés egyszerűbb. Ami nincs kész, az visszamegy a product backlogba. Fontos kimondani, hogy - bár a valóságban az esetek 98% százalékában (mérnöki has alapján végzett becslés, nem hivatalos adat) valóban a következő sprintbe kerül majd - nem kerül át automatikusan a következő sprintbe. Ennek pedig az az oka, hogy egy tudatos döntést szeretnénk kicsikarni a Product Ownerből: kell-e még neki ez a backlogelem? Egyáltalán nem biztos. Elképzelhető például, hogy a céges weblapra húsvét alkalmából animált nyuszikat kellett volna rámolni, de sajnos nem lett kész a sprintben. Mivel a következő sprint már húsvét utánra esik, semmi értelme folytatni a feladatot, egyszerűen ki kell dobni.
Életszerűbb - bár szintén fiktív - példa lehet, ha egy agilis konferencia honlapjára a “call for paper” form nem készül el a sprintben, de a következő sprint végére már lejár a jelentkezési időszak. Így kidobjuk a feature-t, és marad az emailes jelentkezési lehetőség.
Ilyen esetben természetesen, a használt verziókezelő, stb. megoldástól függően még az is elképzelhető, hogy a kidobásnak lesz költsége, így a feature befejezése helyett annak kipucolása jelenik majd meg a következő sprintben, mint feladat.

No de mi legyen a pontokkal? A “majdnem kész” backlogelem eredeti becslése mondjuk 13 pont volt, a csapat úgy érzi, hogy még kb. 5 pontnyi van belőle hátra. Mennyit ér akkor a backlogelem abban a sprintben, ahol nem sikerült befejezni?
A cím sejteti a választ: semmit. Nincs részeredmény (“no partial credit”). A majdnem kész az nincs kész. Nem eladható, nem kiadható, tehát nem ér semmit.
Már csak azért sem, mert ahogy fent olvastuk, lehet, hogy soha nem is lesz a termék része.
De van egy másik fontos oka ennek a szabálynak: azért, mert ha betartjuk ezt a szabályt és sűrűn maradnak félbe nagyobb feladatok a sprintben, csúnya lesz a csapat velocity görbéje.

Nézzük meg a lenti két mintagörbét!

chart1.png

chart2.png

Bár a trend alapján mindkét csapat fejlődik, szépen növekszik a velocity-jük, a második ábra határozottan csúnya. A csúnya görbék pedig nagyon hasznosak, mert bántják a szemünket és arra késztetnek, hogy valamin változtassunk.
Bár egy metrikát mindig könnyű kiszépíteni valódi tartalmi változás nélkül, inkább egy másik utat javaslunk. A lépései:

  • No partial credit szabály bevezetése. Ami nincs kész, az nullát ér.
  • Velocity görbe figyelése. Ha sok a tüske, akkor hiába jó a trend, valami gyanús.
  • Derítsük ki, mi az oka, hogy a csapat sűrűn bukik el nagy feladatokat. Néhány lehetőség:
    • Túl nagyok a backlogelemek
    • Sok a külső függőség
    • Rosszul becsül a csapat
    • Rosszul ütemez a csapat
    • Rossz minőségűek a backlogelemek, sok részlet a sprintben derül ki
  • Szüntessük meg az okot.

A “másik” standup meeting

Egy egyszerű trükkről szeretnénk ma mesélni: egy másfajta standup meetingről.

A napi standup a Scrum leghíresebb - leghírhedtebb eleme; a mai napig vannak vezetők, akik úgy gondolják, hogy ha néhány ember minden nap 10-15 percre körbeáll egy táblát, amin cetlik vannak, akkor ők már agilisak. Annak ellenére, hogy a módszertan ennél jóval komplexebb, a napi meeting valóban fontos elem. És bár látszólag egyszerű, mégis nagyon sokan rosszul csinálják.

A Scrum 3.0-ban eszközölt változások egyikének célja pont a napi standup meeting “megjavítása”. Az a megfigyelés van mögötte, miszerint a legtöbb csapat státuszolásra használja ezt a beszélgetést. Nem ez az eredeti cél. A standup meeting egy tervező meeting, a legkisebb, leggyakoribb rendszeres csapatszintű tervezés helyszíne. Természetesen fontos része a státusz áttekintése, de a célja ennél több: a csapattagok együtt megtervezik, kinek mit kell aznap tennie azért, hogy a csapat (és a sprint) sikeres legyen. Emiatt a régi jól ismert három kérdést is átfogalmazták, és a hivatalos menetrend már így hangzik:

  • Mit csináltál az előző meeting óta, amivel segítetted a csapatot elérni a sprint célját?
  • Mit tervezel csinálni a következő meetingig, amivel segíted a csapatot elérni a sprint célját?
  • Van-e bármi, ami akadályoz téged vagy mást abban, hogy elérjük a sprint célját?

Kicsit színpadias, talán erőltetett, mégis fontos és érdemes így feltenni a kérdéseket, mert sokat tud segíteni a megfelelő fókusz megtalálásában. A csapat feladata nem taskokat végrehajtani. A csapat feladata elérni a sprint célját, a sprint backlogba betervezett backlogelemek leszállításával. A taskok ennek kell alárendelve legyenek.

Megesik, hogy minden fókusz és 3.0-ás standup meeting ellenére a csapat botladozik. Sikertelen, nem készülnek el backlogelemek, kimaradnak taskok, stb… Valami baj van. Ilyen esetben szoktuk azt javasolni a csapatnak, hogy próbálják ki a “másik” standup meetinget. Mi Dexteresnek hívjuk, a szimpatikus sorozatgyilkos után, akinek kalandjain 8 éven át izgulhattunk, és dilemmázhattunk: vajon azért szurkoljunk, hogy elkapják végre, vagy azért, hogy ne?
Aki ismeri a sorozatot, tudja, hogy a főhős a rendőrségen dolgozik. Némelyik epizódban látni, hogy ők is napi meetinggel kezdik a műszakot. Nem a scrumos módon csinálják azonban; tehát nem csapattagonként beszélik át a helyzetet, hanem ehelyett az ügyeken mennek sorra, valahogy így:

  • Mi a legnagyobb prioritású feladatunk?
  • Elkapni a baltás gyilkost.
  • És elkaptuk?
  • Nem.
  • Akkor ki mit fog ma tenni azért, hogy elkapjuk?

Ugyanez a módszer bevethető egy Scrumban dolgozó development teamnél is. A sprint backlogban szépen sorra haladva, fentről lefelé megbeszélni, melyik backlogelem hogy áll, és ha nincs kész, akkor melyik csapattag miben tud segíteni, hogy minél gyorsabban (de persze pontosan, jól, …) elkészüljön a feladat.

Az a tapasztalatunk, hogy ezzel a módszerrel sokkal könnyebb teljes backlogelemeket szállítani. Kombinálni is lehet a két verziót: a sprint első felében elindulni a klasszikus formátummal, majd a második felében áttérni a Dexteresre. Próbáljátok ki!

Kanban vagy Scrum?

A Kanban ismert módszertan, sokan a Scrum alternatívájaként is emlegetik. Valóban van a két módszertan felhasználási területének egy jelentős közös halmaza, ezért érdemes áttekinteni, mi alapján válasszunk.

Természetesen az alapelvünk most is az, mint mindig: az agilitás, a Scrum, a Kanban nem vallások. Tehát kerüljük a hitvitákat, inkább tekintsünk rájuk eszközként és úgy keressük meg a helyüket a világban.

A Kanban legnagyobb vonzereje - sajnos - az egyszerűségében rejlik. Mindösszesen három szabálya van:

  1. Vizualizáld a workflow-t
  2. Korlátozd a párhuzamosan folyamatban lévő feladatok számát
  3. Legyen minden résztvevő fő célja segíteni a feladatok áramlását a folyamatban.

Ennyi az egész. Látszólag triviális, és pont ezért nagyon veszélyes. A fő kockázatai:

  • Könnyen lehet Kanbannak látszó módszertant összerakni. Ez főleg azoknál a szervezeteknél gyakori, ahol csak szóban cél az agilitás, de a valódi változásra nincs hajlandóság. A probléma természetesen az, hogy eredményt így nem hoz, cserébe viszont lejáratja a módszertant.
  • Mivel nagyon megengedő módszertan, a sikerhez hatalmas önfegyelemre van szükség. Azok a szervezetek, amelyeknél pont a megengedőség az érv a Kanban mellett, egyértelműen nem rendelkeznek a szükséges önfegyelemmel, így a kimondatlan szabályokat már rögtön a kezdetektől megszegik, és idővel a három alapszabály is sérül.

Ez utóbbi miatt mondják tapasztalt tanácsadók, hogy termékfejlesztésben Kanbant csak akkor használjunk, ha a Scrum már nagyon jól működik. Ha a szervezet egy viszonylag szigorú módszertan játékszabályait már képes betartani, akkor lehet érdemes egy rugalmasabb irányba elindulni. Mi egy másik helyzetben is alkalmazzuk a Kanbant: ha a Scrum feltételei nem adottak, és a megfelelő támogatás kialakításához szükség van az akadályok tiszta, egyértelmű felfedésére. Például ahhoz, hogy egy Scrum folyamat során minden sprint végén valóban “potentially shippable product increment”-et tudjon szállítani a csapat, elengedhetetlen, hogy a tesztelés a csapaton belül történjen. Találkoztunk olyan csapattal, akik bár nagyon szerettek volna scrumozni, tesztelői kompetencia és infrastruktúra nélkül dolgoztak; úgy, hogy míg egy-egy feature átlagos fejlesztési ideje 4-5 nap volt, a cég közös tesztelői poolja által végzett tesztelés 60-90 napig is elhúzódhatott. Természetesen így a Scrum nem opció, viszont egy tiszta, jól beállított Kanban folyamat nagyon szépen ki tudja hozni ezeket az adatokat és élesen rá tud mutatni a problémára.

Összefoglalva tehát, éretlen szervezetnél a Kanban jó választás lehet a “bottleneck”-ek, szűk keresztmetszetek felfedezésére. Önmagában javulást nem fog hozni, csak rámutat a problémás részekre.
Ezután, ha a feltételek adottak, amíg kialakul a szervezetben a megfelelő érettség és fegyelem, inkább Scrumot javaslunk.
Ha ez már nagyon jól megy, akkor el lehet gondolkodni a Kanbanra váltáson, ha egyáltalán szükség van rá, például mert túl feszesnek érezzük a befagyasztott iteráció okozta megkötéseket, és az üzleti környezet olyan fokú változékonyságot igényel, ahol akár egy két hétre előre tervezés is túl erős kényszer.

Természetesen ez a recept csak irányelv, minden esetben a konkrét szituáció, körülmények, feltételek stb. figyelembevételével érdemes dönteni.

A fentiek mellett azonban fontos kiemelni, hogy a Kanban sokkal több, mint a Scrum esetleges alternatívája a termékfejlesztésben; egy önálló és hatékony módszertan, aminek bevezetése azonban komoly előkészítést kíván. Sok területen használható, az IT-n belül gyakorta alkalmazzák például maintenance/support jellegű feladatok során; IT-től függetlenül HR-folyamatokra, döntési folyamattámogatásra, értékesítésre is használják. Tulajdonképpen a módszertan üzleti területtől függetlenül bárhol felhasználható (mint az egyik kedvenc szimulációs gyakorlatunk bizonyítja, akár egy pizzériában is); ahol folyamat van, ott egy jól bejáratott Kanban sokat segíthet a folyamat javításában.

Less Agile vagy LeSS Agile?

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.

A delegálás szintjei

Bár az agilitástól független téma a delegálás kérdése, mégis úgy látjuk, agilis, vagy afelé haladó környezetben hangsúlyosabban kerül elő és a kapcsolódó kihívások is látványosabbak. Ennek természetesen az a fő oka, hogy sok szervezetben az agilitás egyik várt hatása az önállóbb csapatok születése, akik önszerveződőbbek, nagyobb felelősséget tudnak vállalni és képesek bizonyos döntéseket levenni a vezetőség válláról.
Ez természetesen reális remény, ugyanakkor fontos kimondani, hogy - mint minden változás - ez is egy folyamat, ami tudatos munkát igényel.

Az általunk leggyakrabban látott tévedés ezen a területen az, hogy sok vezető bináris dolognak tekinti a delegálást. “Vagy én döntök, vagy a csapat.” Nincs átmenet.
Sok esetben ez úgy történik, hogy a vezető kiáll a csapat elé, közli, hogy ezentúl ez a ti felelősségetek, döntsetek bátran. A csapat viszont nem kezd el bátran dönteni, ahelyett, hogy motiváltak lennének és büszkén élnének újdonsült hatalmukkal, bizonytalanná válnak és próbálják visszatolni a döntést a vezetőségre.
Ennek számos oka lehet, sok dolog akadályozhatja a sikert, a teljesség igénye nélkül pár példa:

  • a csapat éretlensége: az új helyzettel hirtelen nehéz mit kezdeni
  • információhiány: döntenének, de nem ismert a feltételrendszer, ami segít döntést hozni
  • múltbeli rossz tapasztalatok: akár korábbi döntések, amik során megégették magukat, akár olyan korábbi esetek, amikor határozott javaslatuk volt, amit a vezetőség figyelmen kívül hagyott. Ez utóbbinak persze lehet jó oka, de ha az nem volt megfelelően kommunikálva, akkor a csapatban maradhat sértettség.

A megoldás: folyamatként tekinteni a delegálásra, felmérni a konkrét szituációban megfelelő mértékét és aktívan dolgozni az erősítésén. Mi erre a Management 3.0 részeként ismert Delegation Board, Delegation Poker technikákat szoktuk használni. A linken található anyagok nagyon jól érthetőek és használhatóak, de a teljesség kedvéért itt is gyorsan összefoglaljuk az eszerint az elmélet szerint definiált szinteket:

  1. Tell: A delegáló dönt, és megmondja a döntést a delegáltnak.
  2. Sell: A delegáló dönt, de “eladja” a döntést a delegáltnak.
  3. Consult: A delegáló dönt, de előtte tanácsot kér a delegálttól.
  4. Agree: Közös döntés.
  5. Advise: A delegált dönt, de a delegáló tanácsot ad, illetve ezen a szinten még megpróbálja befolyásolni a döntést.
  6. Inquire: A delegált dönt, a delegáló szeretne tudni a döntésről.
  7. Delegate: A delegált dönt. A delegáló teljesen elengedi a történetet.

Néhány példa saját házunk tájáról: tréningekről. A tréner bizonyos döntéseket különböző mértékben delegál a résztvevők felé.

  • Gyakorlatok időzítése: tell. A tréningjeink során vannak előre időzített gyakorlatok, amelyek helye megvan a tematikában, és vannak olyanok, amiket ad-hoc vetünk be, ha szükségesnek érezzük. Akármelyikről is van szó, a döntés a miénk: most gyakorlat következik.
  • Ebédidő: sell. Mivel előre megegyezünk a helyszínnel, hogy mikorra készüljön el az ebéd, ezt eldöntjük mi. Ugyanakkor a tréning elején megbeszéljük a résztvevőkkel és megpróbáljuk “eladni” nekik, hogy délben ebédelünk.
  • Szünetek: consult. Van egy elképzelésünk, hogy a tematika mely pontjain érdemes szüntetet tartani. Erre építve, de a résztvevők igényeit figyelembe véve döntünk a szünetek gyakoriságáról és hosszáról.
  • A tréning kezdése: agree. Többnapos tréningnél az első nap végén meg szoktunk egyezni, hogy mikor kezdődjön a második nap. A duration fix, ha a társaság szeretne hamarabb kezdeni, akkor korábban végzünk. (Általában azért a 9-től 5-ig intervallum szokott maradni.)
  • Csapatok kialakítása: advise. A szimulációs gyakorlatok során a résztvevők csapatokba szerveződnek. Szempontokat adunk (pl.: legyen a nemek aránya egyenlő), de a konkrét döntés az övék.
  • Szerepek kiosztása a gyakorlatok során: inquire. Azon gyakorlatoknál, ahol szükség van pl. Scrum Master kijelölésére a csapatban, a legtöbb esetben a csapatra bízzuk a döntést, de az eredmény természetesen érdekel minket, hisz a szerencsés kiválasztott máshogy vesz részt a gyakorlatban.
  • Az pedig például, hogy ki hova ül, delegate.

A metrikák veszélyei

Régóta tervezünk írni a metrikákról, mert úgy látjuk, hatalmas félreértés övezi őket - agilitástól függetlenül is.

A metrikák eszközök, amik egy szempontból adnak visszajelzést a vizsgált témáról. Ennyi, és nem több. Fontos kihangsúlyozni, hogy a metrikák nem célok! Valamint azt, hogy nagyon veszélyes pusztán pár szám vagy egy grafikon alapján, a helyzet pontos megértése nélkül megpróbálni következtetéseket levonni. Kényelmes és gyors persze, de nagyon kockázatos. A metrika megmutathatja (de nem feltétlen teszi), ha van probléma, de az okokat a legtöbb esetben nem képes felfedni.

Nézzünk egy konkrét példát! Pár hete egy tréningen azt mesélte egy résztvevőnk, hogy a projektjükről budget-vágás miatt el kellett engedni egy csapatot, és jobb híján a burn-down chart alapján döntötték el, melyik csapat legyen ez. Megkérdezte, mit gondolunk erről a megoldásról. Természetesen azt, hogy hatalmas hiba volt. De miért?

Tegyük fel, hogy két vizsgált csapat burn-down-ja így néz ki:

teama_1.png

teamb.png

Tegyük fel, hogy az elmúlt 8 sprintben hasonlóan alakultak a görbék a csapatoknál. Ha csak ezt a metrikát figyeljük, a legtöbben valószínűleg az “A” csapatot tekintenék jobbnak, őket kell megtartani. Miért? Gyönyörű a görbe íve, szépen megy lefelé, ráadásul el is fogytak a feladatok, tehát minden bizonnyal mindent leszállítottak, amit beterveztek a sprintbe.

Hol van akkor a csapda?

A teljesség igénye nélkül, pár dolog, amit egy-egy ilyen burn-down chart elfedhet:

  • Ha egy csapat minden sprintje sikeres, az mindig gyanús. Lehet, hogy az “A” csapat túl kényelmesre tervezi a sprinteket, ezért sikeresek folyton?
  • Mi lehet amögött, hogy a “B” csapat nem tudja befejezni a sprintjeit?
    • Rosszul becsülnek?
    • Túlvállalják magukat?
    • Esetleg rossz minőségűek a backlogelemeik és ezért nehéz a tervezés?
    • Túl sok részlet van, ami a sprint közben derül ki?
    • Külső függőségeik vannak, amik akadályozzák őket a szállításban?
  • A “B” csapat görbéje néha elindul felfelé. Mit jelenthet ez?
    • Hibás, gyenge taszkosítás?
    • Esetleg a sprinten belüli tesztelés sorra veszi fel a hibákat? De akkor az “A” csapatnál miért nincs ilyen? Lehet, hogy nem tesztelnek rendesen a sprinten belül, és az általuk átadott feature-ökben később sokkal több hiba kerül elő?

Látható, hogy ugyanaz a chart rengeteg dolgot jelenthet, és ezeknek a jelenségeknek csak egy részében mondhatjuk ki, hogy a csapat a felelős. Óvatosan kezeljük tehát a metrikákat! A helyes megoldás bármilyen helyzetben:

  • Válasszunk megfelelő metrikákat
  • És azok akár jó, akár rossz képet festenek, szánjuk rá az időt, hogy megértsük, pontosan mi történik. Nem lehet megspórolni ezt a lépést, oda kell menni ahol a munka folyik és feltenni a megfelelő kérdéseket (például a fenti listában találhatóakat).

Agilis metrikát ötvenes nagyságrendben simán fel tudnánk sorolni - későbbi post-okban tervezünk is pár példát hozni -, de természetesen nem érdemes mindegyiket, mindig használni. A megfelelő metrikák kiválasztásához inkább két támpontot adunk:

  • Bizonyos metrikákat érdemes a szituációk alapján bevezetni. Ez praktikusan olyan ember feladata, aki közelről látja a folyamatot, tehát scrum esetén a Scrum Masteré. Konkrét példa: egy scrum development team sokat panaszkodott nekünk, hogy nem tudnak rendesen scrumozni, mert az üzleti oldal napi szinten meggondolja magát, megváltoztatja az egyes backlogelemek tartalmát. Teljesen tervezhetetlen az életük, folyamatosan dobják ki a félkész fejlesztéseket és ez nagyon frusztráló. Mély együttérzéssel fogadtuk a problémát, de nem tudtuk megvigasztalni őket, ugyanis ilyen helyzetben, ha mi ülnénk az üzleti oldalon, mi is pontosan így viselkedtünk volna. Miért? Gondoljunk bele. Ebben a folyamatban az üzlet annyit lát, hogy bármit kér, azt a fejlesztőcsapat megcsinálja. Ez nem egy rossz helyzet, semmi indíttatás nincs arra, hogy változtassanak a viselkedésükön. Persze, panaszkodnak a fejlesztők, dehát eddigis mindig panaszkodtak… A megoldás ilyen esetben: keresni egy olyan metrikát, ami rávilágít az okozott problémákra. Megkértük a csapatot, hogy minden sprintben gyűjtsék, hogy mennyi munkát kellett kidobni a folyamatos változások miatt. Ezzel az adattal már nem csak azt látta az üzlet, hogy minden kérésük teljesül, hanem azt is, hogy ha egy kicsit előre tudnának tervezni (két hét nem olyan nagy idő), akkor több mint kétszer annyi fejlesztés elkészülhetne, mint jelenleg. Ez elég erős és meggyőző érvnek bizonyult.
  • A fenti példa azokra a metrikákra vonatkozott, amelyeket időszerűen használunk. Természetesen vannak olyan metrikák, amiket érdemes folyamatosan figyelni. Ezek kiválasztására érdemes az alábbi mátrixot figyelembe venni:

metrics_matrix.png

A mátrix egyik dimenziója azt mutatja, hogy milyen folyamatra vonatkozik a metrika: részfolyamatra (pl.: fejlesztés, tesztelés, üzemeltetés, stb.), vagy a teljes end-2-end value streamre. A másik dimenzió pedig, hogy ez a metrika érdekli-e az ügyfelet. Ügyfél alatt mindig a termék ügyfelét értsük, tehát egy outsourcing vagy alvállalkozó cégnél nem a megrendelőt, hanem a termék vásárlóját.
A legtöbb szervezet az ügyfél számára lényegtelen, részfolyamatra vonatkozó metrikákra koncentrál. Kedvenc példánk erre a code coverage. Nincs baj az ilyen metrikákkal, csak túl vannak hangsúlyozva. Amire az igazi fókuszt helyezni kéne, az a szemközti kvadráns: az ügyfél számára fontos, end-2-end metrikák. Például: time-to-market, hiba trendek, szállított üzleti érték, customer retention ...

Befejezésül még egy példa a metrikák megtévesztő erejére: a magyar futballválogatott idén 30 éve nem kapott gólt EB-n. Örülünk? :)

Skillek és csapatok

A legtöbb hozzászólás eddig a “Scrum versus egyéni fejlődés, karrierút” postunkhoz érkezett. Köszönjük a hozzászólóknak az aktivitást, mivel az évvégi hajrában elmaradtunk a válaszadással, most hadd reagáljunk komment helyett inkább egy teljes postban.

Szerző: hrgy

"Csupán annyit jelent, hogy ne az határozza meg, mit csinálunk, hogy mire van emberünk, hanem az, hogy mire van szükségünk az üzleti sikerhez. "

Jujj, ezt nagyon gyorsan tisztaba kell tenni, mert eleg nagy gondok szoktak abbol szarmazni, hogy ezt emberek szo szerint veszik, es olyasmiket is bevallalnak projektbe, amire egyaltalan nincs szakertelem a csapatban.
...

Köszönjük a pontosítást! Az eredeti cikk a csapatban már meglévő skillekről szólt, a teljesen hiányzó tudásról nem szóltunk, bár valóban fontos kérdés. Amennyiben a felmerülő üzleti igények új szaktudást igényelnek, a következő szempontokat szoktuk figyelembe venni:

  • Biztosan kényszerítő erejűek a körülmények? Például ha egy java fejlesztőcsapat kap egy feladatot, amit python-ban kell megcsinálni, honnan jön ez az igény és valós-e?
  • Ha igen, akkor kérdés, hogy milyen sűrűn várható a jövőben ezt az új tudást igénylő feladat, illetve mennyi a betanulás költsége. Ha a betanulás drága, de ritkán lesz ilyen feladat, egyszerűen nem éri meg - túl nagy lesz az opportunity cost. Ebben az esetben érdemes a feladatot átadni másnak, akár cégen kívül is. De akár, ahogy hrgy a hozzászólása folytatásában írja, a feladat elengedése is opció.
  • Ami tovább árnyalhatja a döntést, az az új feladat elvárt minősége. István kedvenc példája, hogy ha egy 2 hétig élő promóciós website-ot fejlesztünk, amin termékvonalkódokat lehet feltölteni és ezzel pólót nyerni, ez egy olyan termék, aminél az elvárt minőségi szint nem feltétlen kell, hogy magas legyen. Rövid életű termék, tehát a továbbfejleszthetőség nem fontos, és valljuk be, nem is olyan kritikus termék, hogy egy-két hibától összedőljön a világ. Ellenben ha egy vakbélműtétet végző robotot programozunk, egészen más az elvárt minőségi szint. Az elsőhöz hasonló esetekben akár még a “pár óra google” utáni összetákolt megoldás is elegendő lehet - csak tisztán kommunikáljuk, mit lehet és mit nem lehet elvárni az elkészült terméktől.

Szerző: tnsnames.ora

Nekem más problémám van a posztbeli üzenettel. Nekem nagyon hiányoznak a számok.
Létezik egy valid(?) prekoncepció, hogy gazdaságilag a projekt szempontjából így lehet a legolcsóbb, csak sosem látom hozzá a valós és teljeskörű, pláne projektekre is aggregált visszaméréseket. Számok nélkül ködszurkálás is lehet az egészből: "vagy talált vagy nem".

A projektmódszertanon, megrendelőn, illetve gazdasági lehetőségeken felül vannak egyéb komponensek is a teljes rendszerben: pl:: résztvevő emberek és jövőik. Több lesz-e az ember és jövője avgy sem az ilyen szemlélet mentén? Akar-e, tud-e erre bárki is figyelmet fordítani? Arról nemis beszélve létezhet-e elfogadható optimum, pláne konszenzus, a felmerült szempontok felett?

Személyes tapasztalataink vannak a kérdésekkel kapcsolatban, sajnos publikálható (élő NDA-kat nem sértő) számaink nincsenek. És természetesen nincs is egyértelmű szabály sem, minden helyzet egyedi és átfogó megértést igényel. Vannak viszont konkrét példáink, amik segíthetnek alátámasztani az álláspontunkat:

  • Az “így lehet a legolcsóbb” mellett fontos szempont az is, hogy így lehet a leggyorsabb. Dolgoztunk olyan, 4 fős termékfejlesztő csapattal, ahol a termék négy modulra volt bontva, és mindegyik modulnak volt egy felelőse; csak ahhoz értett. A Product Owner minden sprint planningen küzdött, mert egyszerűen az üzleti célok és igények nem egyenlő arányban oszlottak el a négy modul között, volt olyan modul, aminek a fejlesztését a következő negyedévben egyáltalán nem tervezték. Természetesen nem akarták elengedni a megbízható fejlesztőt, aki az aktuálisan alacsony prioritású modul felelőse volt; szerencsére a csapat is gyorsan megértette a problémát, nyitott volt a változásra és mindenki megtanult egy másik modult.
  • Résztvevő emberek és jövőik” - A fenti példában ugyanabban az eszközben fejlesztett modulokról van szó. Ilyenkor is felmerülhet az ízlés kérdése - van olyan fejlesztő, aki csak back-endet, vagy csak front-endet szeret fejleszteni. Azokban az esetekben viszont, ahol már más eszköz megtanulása a kérdés, ez még nehezebb lehet. Személyesen ismerünk olyan ex-blackberry fejlesztőt, aki ha annak idején nem lett volna nyitott arra, hogy megtanuljon androidot fejleszteni, most lehet, hogy munkanélküli lenne. Ha elengedjük azt a - szerintünk irreális - célt, hogy mindenki mindenhez értsen, és behelyettesítjük azzal, hogy minél több csapattag minél több dologhoz értsen, akkor tapasztalatunk szerint megfelelően kommunikált célok mentén, a megfelelő körülmények (idő, támogatás, energia) biztosítása esetén a csapattagok nyitottá tudnak válni a tanulásra.

Hisszük, hogy létezhet pillanatnyi optimum, de mivel változó világban élünk, az ideális skill-elosztás is változhat (ahogy az első komment is utal erre). Erre megoldásként mi a skill matrix-ot szoktuk használni:

  • összegyűjtjük, hogy milyen technikai és soft skillek szükségesek a csapatban
  • minden csapattagnál bejelöljük, mennyire ért az adott témához - saját bevallás alapján, de a csapaton belül szinkronizálva, hogy reális képet kapjunk

Ez alapján látszik, milyen tudás hiányzik, mi az, ami megvan, de kockázatosan kevesen értenek hozzá. Fontos viszont, hogy csak akkor működik a skill matrix, ha rendszeresen - mondjuk negyedévente - frissítjük. Mind az aktuális tudásszinteket, mind pedig a szükséges skill-ek listáját.

Tréningen egy közismert csapatra elkészített skill matrix-szal szoktuk bemutatni az eszközt:

skillmatrix_copy.jpg

Agile és Lean

Közismert tény, hogy az agilitás Lean gyökerekkel rendelkezik. Sajnos azonban a kölcsönvett Lean alapelvek csak implicit kerültek beemelésre a módszertanba, eredeti formájuk elveszett. Emiatt lehet az, hogy úgy látjuk, a Lean a legtöbb esetben nem kap elég hangsúlyt és tudatos fókuszt agilis átállás / bevezetés során.

Leginkább a következő esetekben szokott felmerülni a Lean:

  • amikor egy csapat rájön, hogy a Scrum nem megfelelő módszertan nekik, ezért elkezdenek Kanbanozni (“Lean Kanban”)
  • amikor a szervezetben felmerül az igény, hogy az agilitás kezdjen el az IT-n túl is terjedni a szervezetben (“Lean Software Development”, pl.: value stream mapping, silóbontás)
  • olyan skálázási módszertan bevezetésekor, ami készítői szerint Lean technikákat használ (pl.: SAFe)
  • vagy teljesen függetlenül az IT-től, amikor például egy bank szeretné a folyamatait optimalizálni.

Természetesen mind a négy helyzetben lehet érték. Még több értéket kaphatunk azonban a módszertantól, ha rögtön az elejétől kezdve tudatosan kimondjuk és követjük a Lean alapelveket is. A Lean központi gondolata, hogy a szervezet célja maximális értéket teremteni és szállítani az ügyfeleinek, miközben a folyamatokban lévő veszteséget, felesleget (waste) minimálisra csökkenti, úgy, hogy ezalatt egy öntanuló-önfejlesztő céges kultúrát épít fel és tart meg.

Az értékteremtés megjelenik az Agile Manifesto első alapelvében: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”.
Az önfejlesztés pedig az utolsóban: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”.
A veszteségminimalizálás kapja a legkisebb hangsúlyt. A Scrum - ha jól implementáljuk - nagyon erős abban, hogy a termékfejlesztés legnagyobb potenciális veszteségét kiküszöböljük, mégpedig azt, hogy olyan terméket fejlesztünk, ami utána nem kell senkinek. Erről szól a rendszeres szállítás és feedback.

Mindhárom pont tovább erősíthető azonban a tudatosság növelésével, Lean technikák beemelésével. Ezért is működünk együtt az IdeaLean Consultinggal, amely a szolgáltató cégek Lean tanácsadójaként az agilis bevezetési projekteket is segíti. Mindák Ildikó közérthető, közvetlen hangvételű Lean blogját szeretnénk ajánlani nektek: idealean.blog.hu. Jó olvasást! :)

Csapat, vagy csak csoport?

Gyakori jelenség a csapat (team) és csoport (group) fogalmának keverése. Fognak néhány embert, azt mondják nekik, hogy ti egy csapat vagytok, esetleg még közös irodába is ültetik őket, aztán várják a csodát. A csoda pedig nem jön. Mert annak, hogy egy csoport csapattá váljon és akként is működjön, feltételei vannak:

  • Közös cél. Egy pék, egy festőművész és egy ipari alpinista sohasem lesznek csapat. Mindhárman fontos, értékes munkát végeznek, de nem tudják egymást támogatni a feladatuk elvégzésében és nincs közös céljuk. Haverok lehetnek, de csapat soha. Egyesek közös feladatnak, mások közös küldetésnek (mission) nevezik ugyanezt.
  • Tiszta keretek, korlátok. Divatos kifejezés az önszerveződés az agilitásban, de veszélyes. Az egyértelmű keretek nélküli önszerveződésből káosz lesz. A csapatnak tudnia kell, milyen kérdésekben dönthet, miben nem, illetve milyen folyamatok mentén működhet együtt a szervezet többi részével. A legegyszerűbb példa a sok cégnél ismert törzsidő fogalma: mi az az idősáv, amikor a munkahelyen kell tartózkodni?
  • Hatalom. Szerencsétlen fordítás, az eredeti angol authority kifejezés jobban leírja, miről van szó. A csapatnak kell legyen joga az előbb említett korlátokon belül, saját hatáskörben döntéseket hozni. Kézenfekvő scrumos példa a feladatkiosztás: a csapat a napi standup meetingen megbeszéli, melyik csapattag melyik feladattal fog foglalkozni. A csapaton kívül ebbe senkinek nincs beleszólása.
  • Stabilitás. A gyakran változó összetételű csoport soha nem válik csapattá. Idő kell az embereknek ahhoz, hogy megismerjék egymást emberileg és szakmailag, megtanuljanak együtt dolgozni, kialakítsák a saját munkamódszereiket, nyelvezetüket, stb. Minden alkalommal, amikor valaki csatlakozik a csapathoz, vagy kiválik belőle, ez a folyamat újraindul.

A fenti feltételek megteremtésén túl is van pár trükk, ami segíthet felgyorsítani a csapattá válást:

  • Identitás. Nem véletlen, hogy sok csapat nevet választ, ez erősíti az összetartozás érzését, segíti a megkülönböztetést a “mi” és a “többiek” között.
  • Fizikai környezet. Az agilis team-ekre jellemző rengeteg low-tech vizualizációs eszköznek (information radiator, story map, kinyomtatott chartok, stb.) az információ megjelenítésén kívül az is nagy haszna, hogy egyedivé, otthonossá teszi a csapat területét.
  • Közös erőforrások. Közös, de a csapat számára allokált erőforrások, melyek beosztása a csapat felelőssége és feladata. A fizikai környezethez hasonlóan a “miénk” élményt erősíti.
  • Értékek. Közös értékek, nem csak vezényszó vagy marketing jelmondatok, de közös értelmezés által is szintén segíthetnek összehozni a csapattagokat.

Acceptance Criteria vs Definition of Done

Egy időre megtörve a korábbiakban vizsgált cikk elemzését, pár, sokszor félreértett fogalom tisztázásáról szeretnénk írni nektek. Kezdjük rögtön az Acceptance Criteria és a Definition of Done kérdésével. Sok csapat keveri a kettőt: D.o.D-nek hívja azt, ami valójában az A.C., és ami ennél sokkal nagyobb baj; a D.o.D. az ilyen csapatoknál teljesen hiányzik.

Akkor tekintünk késznek egy backlogelemet, ha mind az Acceptance Criteria-nak, mind a Definition of Done-nak megfelel. A kettő között a különbség az, hogy az A.C. azoknak az egyedi feltételeknek (elfogadási kritériumoknak) a gyűjteménye, amik csak az adott backlogelemre vonatkoznak, míg a D.o.D. azon közös feltételek gyűjteménye, amit minden egyes feladatnak teljesíteni kell a készség kimondásához.

Nézzünk egy konkrét példát!

Legyen a termékünk egy mobilalkalmazás, ami kottaolvasás gyakorlásában segíti a felhasználókat. A termék backlogjának egy eleme lehetne a következő user story:

Én, mint kezdő zongorista
Szeretnék violin- és basszuskulcsban írt kottákon is gyakorolni
Azért, hogy mindkét kulcsban megtanuljak blattolni.

A story Acceptance Criteria-ja lehet pl.:

  • A gyakorlás indításakor az alkalmazás megkérdezi, milyen kulcsban szeretne gyakorolni a felhasználó (violin / basszus)
  • A hangjegyek elhelyezése a kiválasztott kulcsnak megfelelő
  • A kotta scrollozása közben a kulcs nem scrollozódik, fixen látszik a sor elején
  • stb.

Mivel a Definition of Done a teljes termékre, a termék minden backlogelemére vonatkozik, abban általánosabb elvárások vannak, pl.:

  • Minden változás be van commit-olva a fő branchbe
  • Minden felület megfelel a UX guideline-nak
  • Az alkalmazás minden képernyője mind portrait, mind landscape módban használható (a teljes képernyőtartalom látszik, minden interakció elérhető, …)
  • stb.

A Definition of Done-ban mi a következő 6 kategóriát szoktuk megkülönböztetni:

  • Kódminőségi elvárások
  • Fejlesztői tesztelési elvárások
  • Funkcionális tesztelési elvárások
  • Dokumentációs elvárások
  • Általános üzleti követelmények
  • Nem-funkcionális követelmények

Termékfejlesztés az agilitásban

A mai bejegyzéshez a sorozatban feldolgozott cikk-ből ezt a mondatot (legalábbis egy részét) választottuk: “Product development and architecture aren't the programmer's job, because they take longer than two weeks. Rather, the programmer works on atomized feature-level ‘user stories’.” - “A termékfejlesztés és az architektúra nem a fejlesztő feladata, hiszen az tovább tart két hétnél. Ehelyett a programozó atomi, feature-szintű ‘user story’-kon dolgozik”.

Először vizsgáljuk meg, mit jelent a termékfejlesztés kifejezés. (A komplex architektúráknak külön bejegyzést szentelünk majd.) A businessdictionary.com szerint a termékfejlesztés “termékek létrehozása új vagy különböző jellemzőkkel, amik új vagy további előnyöket biztosítanak a vevő számára. A termékfejlesztés állhat létező termék módosításából vagy bemutatásából, vagy egy teljesen új termék kialakításából ami újonnan definiált vevői szükségletet elégíg ki, vagy egy piaci rést tölt be”.

Mind ebben a definícióban, mind az agilis kiáltványban hiba, hogy nem tesz különbséget vevő és felhasználó között. Ez a kettő sokszor egybeesik, de nagyon sokszor nem: más veszi meg a terméket és más fogja használni. Ideális esetben mindig a felhasználó számára készülne a termék, de tudjuk, előfordul, hogy egy bizonyos funkcióra csak azért van szükség, hogy el lehessen adni a terméket; használni senki nem fogja. Ez nem tragédia, de érdemes tudatosítani, mit miért csinálunk és annak megfelelő energiát fektetni bele.

Az egyszerűség kedvéért engedjük most meg ezt a pongyolaságot, és vizsgáljuk így a termékfejlesztés kérdését. Ha elfogadjuk a fenti definíciót, akkor kijelenthetjük: soha nem volt még annyira a fejlesztő feladata a termékfejlesztés, mint most. Sőt, nem csak a fejlesztőé, a teljes fejlesztőcsapaté, amiben természetesen a tesztelők is helyet kapnak.

Valóban user story-kon dolgoznak a csapattagok, de mi az a user story? Egy kezdetben szándékosan alulspecifikált vevői igény megfogalmazási mód, mely segít minden résztvevőnek beleélnie magát a felhasználó szerepébe és kikényszeríti az igény közös megértése és a legjobb megoldás megtalálása érdekében az üzlet és fejlesztés közötti párbeszédet.

Az üzlet nem azt kommunikálja a fejlesztés számára, hogyan működjön a rendszer, hanem hogy mi az a probléma, amit a rendszerrel meg szeretnénk oldani.

A user story formátum másik nagy előnye, hogy vertikális feladatokat definiál: egy felhasználói igény kielégítéséhez a rendszer minden rétegében szükséges módosítások egy story részét képezik. Ellentétben a horizontális megközelítéssel, amikor egy feladat pl. új adatbázistáblát tervezni, sok esetben a valós felhasználói szükségletek, a táblában tárolandó adatok használati módjainak pontos ismerete nélkül.

A követelményeket tehát úgy daraboljuk és úgy fogalmazzuk meg, hogy a fejlesztőcsapat tagjai felhasználói szemmel tekinthessenek a rendszerre, és így gondolhassák végig a felmerült feladatot. Ha egy követelmény nem ad semmilyen értéket a felhasználónak, nem fogjuk tudni jól megfogalmazni user story-ként. Klasszikus példája ennek, amikor a story hazudik, egy fejlesztési ötletet “ráfogunk” a felhasználóra, pl.:

Én, mint az online hírportál olvasója
Szeretném, ha az oldal tele lenne mindenféle felugráló reklámokkal, amik miatt az engem érdeklő cikket alig bírom elolvasni
Azért, hogy a kiadónak legyen valami bevétele

Csapatmorál az agilitásban

Az előző bejegyzésben elemzett mondat folytatódik; a teljes mondat így hangzik: "If you carry this way of working on for months or years, you get a lot of technical debt and you get low morale" - "Ha hónapokon, vagy éveken át így dolgozol, rengeteg technikai adósságot halmozol fel es alacsony lesz a morál".

Azért különösen érdekes az állítás második fele, mert az agilis módszertanok mellett elég gyakran megjelenő érv, hogy javítja a morált. Egy esettanulmányban 30%-os fizetésemeléssel egyenrangú mértékű javulásról számolnak be: “Besides being extremely beneficial, working using Agile practices has boosted our company's team morale much better than if I were to give employees a 30% raise”. (IBM, ThoughtWorks, Forrester)

Mik azok a faktorok, amik az agilitásban különös hangsúlyt kapnak és jó hatással vannak a morálra? Mindegyik kétélű fegyver; ha nem, vagy nem úgy használjuk őket, ahogy módszertanilag ki vannak találva, visszaüthetnek...

  • Ügyfélközpontúság, ügyfélközeliség és ügyfél-feedback
    Három erősen összekapcsolódó dolog, amiket ha sikerül megvalósítani, a rövid iterációs hossz miatt a folyamatos siker érzését adják, valamint azt az élményt, hogy a termékünket valóban használják és egyre jobban szeretik.
    Egy tradícionális modellnél csak ritkán, nagyon hosszú időközönként érhető el a siker és a hasznosság érzése, sőt, rossz esetben, ha nagyon félrement a fejlesztés a fentiek hiánya miatt, akkor soha.
    Amennyiben azonban az ügyfél nem létezik (elefántcsonttoronyban megálmodott terméken dolgozunk, ami egyáltalán nem biztos, hogy bárkinek is kell), távol tartjuk a fejlesztéstől vagy csak szimuláljuk, tehát valódi piaci tapasztalat és visszajelzés nélkül halad a fejlesztés, a termék kiadása után ugyanúgy előfordulhat, hogy kiderül: feleslegesen dolgoztunk. Mivel azonban az agilisról szóló reklámanyagok mást ígérnek, ez esetben sokkal nagyobb lesz a csalódás.
  • Közös gondolkodás
    Az agilitás által definiált üzlet-fejlesztés együttműködés fő jellemzője. Az üzlet rendszerkövetelmények helyett felhasználói problémákat és üzleti célokat hoz, amelyek megoldására a fejlesztőcsapattal közösen gondolkodva találják meg az utakat (üzletileg) és amelyek technikai megoldását a csapat saját hatáskörben, önállóan találja ki. Ily módon a csapattagok sokkal inkább be vannak vonva a termékfejlesztésbe, és nagyobb teret kap egyéni szakértelmük, kreativitásuk is.
  • Minőség
    Mind technikai, mind funkcionális szinten erősödik a minőség azáltal, hogy a tesztelést a fejlesztés részévé tesszük, kimondjuk, hogy a technikai kiválóságra folyamatosan figyelni kell és Scrum esetén a Definition of Done-nal beállítjuk mindkét minőségi szintet. Jó minőségű terméket szállítani nagyobb büszkeség, szívesebben mesélünk róla a barátainknak is.
  • Folyamatfejlesztés
    A retrospektívek valódi jelentése, hogy ezen módszertanok esetén nem a vezetőség, rosszabb esetben egy külső szakértő határozza meg és kényszeríti a csapatra a követendő folyamatokat, hanem egy közös kezdeti megegyezés után a csapat hatalmat kap a saját folyamatai fölött (bizonyos korlátok között, természetesen) és lehetősége lesz azt rendszeresen fejleszteni, javítani.
  • Csapatmunka
    Egy kreatív, egymást segítő, a közös cél felé együtt haladó csapatban dolgozni nagyon jó érzés, emberileg és szakmailag is. Idő, amíg egy friss csapat ilyenné tud válni, ezért is nagyon fontos a csapat stabilitásának megőrzése.
  • Scrum értékek
    A fenti pontokban implicit megjelennek, de fontos külön is kiemelni: a Scrum által definiált öt érték sikeres megteremtése szintén nagy, pozitív hatással van a morálra. Az öt érték pedig: nyíltság (openness), fókusz (focus), tisztelet (respect), bátorság (courage) és elkötelezettség (commitment).

Technikai adósság

“If you carry this way of working on for months or years, you get a lot of technical debt …”, vagyis “ha hónapokon, vagy éveken át így dolgozol, rengeteg technikai adósságot halmozol fel …”, írja az agilis módszertanokról a sorozatunkban elemzett cikk. Nagy hiányossága az írásnak, hogy csak kijelent, de nem indokol; így vitába szállni sem lehet vele. Vita helyett tehát inkább elmondjuk, tapasztalataink szerint mi okozhatja a fenti helyzet kialakulását, és hogyan lehet kivédeni azt.

A technikai adósság keletkezésének gyökéroka, hogy a sebesség oltárán feláldozzuk a minőséget. Itt hívjuk fel a figyelmet arra, hogy ezek az okok nem csak agilis környezetben merülnek fel. Sok megjelenési formája van ennek, néhány példa:

  • Kritikus hibát gyorsan kell javítani. Ilyen esetben a hackelés teljesen helytálló stratégia: ha éles rendszerhiba miatt mondjuk óránként egymillió dollárt veszít a cég, senkit nem érdekel és nem is szabad, hogy érdekeljen a megoldás eleganciája; a gyorsaság a kulcs. A probléma abból fakad, hogy miután a hibát elhárítottuk, más feladatok lesznek sürgősek és a rendrakás elmarad.
  • Hasonló eset, ha kritikus fejlesztést kell gyorsan elvégezni. Ebben az esetben is új irányba állítjuk a fejlesztőcsapatot, amikor már működik az új funkció, és a rendrakás ismét elmarad.
  • Előfordulhat az is, hogy egy, a korábbi követelményeknek tökéletesen megfelelő kóddal kapcsolatban olyan új igény merül fel, aminek a lefejlesztése a kód átstrukturálását igényelné. Ha nem vállaljuk fel, hogy az új igény fejlesztési költségének része a meglévő rendszer szükség szerint átalakítása, ismét nem lesz idő megfelelő minőségű munkát végezni.
  • Megtörténhet; különösen, ha új technológiával kezd el dolgozni a csapat, hogy a korai megoldásokról kiderül: nem időtállóak. Ahogy egyre jobban megismerik az új technológiát, sorra fedezik fel, mit hogyan lehetett volna jobban megoldani. Természetesen nem kell minden felmerülő ötlet esetén rögtön átírni az egész kódbázist; de ha soha nem hajtjuk végre ezeket a módosításokat, egész biztosan csak halmozni fogjuk az adósságot.

Akárhogy is jutottunk el a technikai adósságig, minden esetben feszültséget szül az üzleti és a fejlesztési oldal között. Az üzlet frusztrált és nem érti, miért lassul folyamatosan a fejlesztés; a fejlesztés szintén frusztrált, mert az üzlet nem hagy időt a refaktorálásra és folyamatosan nő a nyomás.

Az agilis kiáltvány egyik alapelve így hangzik: “A műszaki kiválóság és a jó terv folyamatos szem előtt tartása fokozza az agilitást” (A félreértések elkerülése végett, a “terv” szó itt a design, mint architektúra terv fordítása, nem pedig a plan, mint projekttervé). Talán túl megengedő a megfogalmazás; kimondhatnánk azt is, hogy a műszaki kiválóság szem előtt tartása nélkül nem lehet fenntarthatóan és agilisan dolgozni.

Muszáj tehát a refaktorálást a napi munka részévé tenni, és amennyiben ez nem elég, nagyobb szabású átalakításra van szükség, annak is teret kell adni a fejlesztés során.

Általános jelenség, hogy a fejlesztők, ha tehetnék, folyamatosan csinosítanák a kódot, az üzlet pedig mindig rohanna tovább előre. Eközött a két véglet között kell megtalálni az egyensúlyt. Két utat ajánlunk erre:

  • A fejlesztési oldalnak “el kell tudnia adni” a technikai adósság csökkentését célzó feladatokat az üzlet számára.
    Nekünk leginkább az vált be, ha ilyen esetben nem azt keressük, miért fontos végrehajtani a szóban forgó refaktorálást, hanem azt, milyen következménye lesz annak, ha elmarad. Pl.: “a jelenlegi megoldással maximum 25 konkurens felhasználót tudunk kiszolgálni”, “3 MByte-nál nagyobb file-oknál nagyon belassul a feldolgozás, akár több percig is eltarthat”, “nem lehet automata tesztet illeszteni a kódhoz, így minden egyes release előtt kézzel kell végigtesztelni ezt a modult”, …
    A “mit veszítünk, ha nem csináljuk meg” gondolkodás segít üzleti nyelvre fordítani a refaktorálás technikai feladatát, és abban is segít, hogy kiszűrje azokat a módosításokat, amiket csak a személyes szépérzékünk kielégítése kedvéért szeretnénk elvégezni.
  • Ha már felépült a megfelelő kommunikáció üzlet és csapat között a technikai adósságról, sok esetben létrejön egy megállapodás, miszerint a csapat a kapacitás x%-át ilyen jellegű feladatokra fordíthatja. Ez megkíméli a Product Ownert attól, hogy számára esetleg nem érthető backlogelemeket kelljen priorizálnia és a megfelelő szintre viszi a döntést: ahol a tudás és az információ rendelkezésre áll. Egyúttal - mivel véges budget-ből gazdálkodhat a csapat - ezzel a módszerrel is ki tudjuk védeni a valódi értéket nem adó technikai feladatokat: a csapat sajnálni fogja ezekre az időt.

A fentiek alapján nekünk az a személyes véleményünk, hogy jól működő agilis környezetben a technikai adósság problémája egy beismert és tudatosan kezelt kérdés, és sokkal nagyobb a valószínűsége annak, hogy ezek az adósságok tényleg “kifizetésre kerülnek”, mint egy hagyományos környezetben.

Scrum versus egyéni fejlődés, karrierút

Az előző postban hivatkozott cikk elemzését a következő félmondattal folytatjuk: “Scrum practice of ignoring peoples' career goals and their individual talents” - “a Scrum figyelmen kívül hagyja az emberek karriercéljait és egyéni tehetségüket, képességeiket”.

Sajnos tény, hogy van bőven olyan Scrum implementáció, ahol a fenti állítás igazzá vált. Az is tény, hogy ennek a problémának a kivédésére az alap, “out-of-the box” Scrum nem ad megoldást. Emiatt lehet ugyan bírálni a módszertant, de szerintünk felesleges. Sokkal fontosabb felismerni, hogy a Scrum - alkotóinak bevallása szerint is - egy projektmenedzsment módszertan. Önmagában tehát nem old meg mindent; egy sikeres implementációnak feltétele kiegészíteni mind technikai, mind emberi (people management) praktikákkal.

Mire van tehát szükség ahhoz, hogy az egyéni karrierút megmaradjon?

A probléma egyik gyökere, hogy a Scrum bevezetés következtében a termék leszállításához szükséges különböző szakmájú emberek (a legegyszerűbb lebontásban mondjuk fejlesztők és tesztelők) egy csoportba kerülnek, hogy együtt teljes feature-öket tudjanak kiadhatóan (letesztelten, ...) szállítani. Sok esetben a Scrum előtt egy munkatárs akár 30-40 azonos szakmájú ember között dolgozott nap mint nap és így folyamatos lehetősége volt velük kommunikálni, problémákat megvitatni, tanulni tőlük. A módszertan bevezetése után hirtelen egy olyan csapatban találja magát, ahol ebből a szakmai közösségből csupán 1-2 fő maradt körülötte. Drasztikusan lecsökkent tehát az információcsere mértéke és a fejlődés lehetősége.
A sikeres működés feltétele, hogy bár valóban szét lettek szórva az emberek a Scrum teamekbe, mégis megtartsuk a korábbi szakmai közösségeket. Ennek a megoldására született a community of practice, melyről egy saját bejegyzést is tervezünk írni.

Az egyéni karrierút másik akadálya lehet, hogy a módszertannal bevezetésre kerül a csapatfelelősség fogalma is. Ez valóban okozhatja azt, hogy az egyének úgy érzik, nincs elég ráhatásuk saját sikerükre, másoktól függ az elismertségük. Ezt még egyszerűbb megoldani: a fejlesztési- és értékelési rendszer részévé kell tenni olyan egyéni célokat, amikért egyedül is tud küzdeni a munkatárs. Természetesen fontos, hogy ezek a célok szinkronban legyenek a szervezet, a termék és a csapat céljaival. Ilyen cél lehet például egy belső szakmai előadás tartása a csapattársaknak, egy új technológia megismerése, stb.

A karrierút-kérdésen túl azt is felhozza a cikk, hogy a Scrumban figyelmen kívül hagyjuk az egyének tehetségét, képességeit.

Csak tippelni tudunk, miért gondolhatja ezt a szerző. A módszertannak célja, hogy a csapattagok a termék lehető legszélesebb részén tudjanak dolgozni, megtanulják egymás területeit. Ez azonban nem azt jelenti, hogy mást kell csinálni, mint amiben jó az ember. Csupán annyit jelent, hogy ne az határozza meg, mit csinálunk, hogy mire van emberünk, hanem az, hogy mire van szükségünk az üzleti sikerhez. Amennyiben valakinek a kedvenc területén éppen van feladat, természetesen - a csapattal egyeztetve - nyugodtan csinálhatja azt ő. Ha azonban ilyen feladat nincs, akkor is fontos, hogy értékes része tudjon maradni a teamnek és aktívan kivegye részét a munkából.

Stretch Leadership konferencia

Stretch nemzetközi Leadership & Management konferencia idén 3. alkalommal kerül megrendezésre a Prezi, a Ustream és az Ericsson jóvoltából. A rendezvény hasznos új ismereteket ad bármilyen vezető, manager, coach számára, aki új módszereket szeretne megismerni világszinten elismert szakemberektől.

Az idei Stretch 15 nemzetközi előadóval és számos gyakorlatias Open Space-szel várja a résztvevőket, melyek segítenek a színpadon hallottakat feldolgozni a következő 6 fő témában:

  • Organizational agility
  • Experimental mindset & learning organization
  • Change management
  • Embracing self-organization
  • Making the organization more personal
  • Finding the purpose of the organization

A konferencia pontos programját itt találjátok. Ha a SprintConsultingStretch kóddal regisztráltok az eseményre, most 20$ kedvezményt is kaptok. :)

Egy kis ízelítő a tavalyi konferenciáról:

Stretch Leadership Conference 2014 summary video from Conferences on Vimeo.

Helytelen ügyfélviselkedés?

2015. március 24-én jelent meg egy cikk a quora.com oldalon arról, hogy miért gondolják prominens cégek fejlesztői az Agilis fejlesztési módszertanokat nonszensznek. A cikk konklúziója szerint az agilis modell csak rövid, pár hetes projekteknél használható, amikor nagyon gyorsan kell szállítani. A cikk egységes, és a benne lévő következtetések logikus eredményei a benne felsorolt jelenségeknek; a helytelenségét az adja, hogy rengeteg félreértés van benne az agilitással kapcsolatban. Ezeket a félreértéseket szeretnénk a következő bejegyzésekben sorra venni.

Már a bevezetésben van egy félmondat, amit érdemes jobban kielemezni: “changing requirements and other potential bad behavior from the client”, azaz “változó körülmények, és egyéb, potenciálisan helytelen ügyfélviselkedés”.

A “potenciális” kifejezés gyengíti a mondat erejét; szerencsére nem sugallja azt a szerző, hogy minden követelményváltozás helytelen viselkedés lenne. De vajon mit tekinthetünk mégis annak?

Változás és változás között is van különbség. A döntő szempont sohasem a változás ténye, hanem annak forrása.

Ha a változás oka félreértés, kapkodás, meggondolatlanság, figyelmetlenség, akkor feltétlen “rossz” változásról beszélhetünk. Ennek leggyakoribb tünetei az üzlet részéről a “nem így értettem” / “nem így gondoltam”, a fejlesztés részéről pedig a “nem volt leírva” mondatok.
Amennyiben azonban a változás oka például új, korábban elérhetetlen üzleti információk megszerzése, üzleti vagy technikai fejlődés, vagy új megoldások felfedezése az ügyfelek jobb kiszolgálása érdekében, ez tekinthető “jó” változásnak.

Az agilis módszertanok célja minden esetben az előbbiek kiküszöbölése és az utóbbiak előfeltételeinek megteremtése. Nézzünk ezekre néhány példát!

Az átfogó, a fejlesztés előtt teljesen elvégzett követelményelemzés elhagyásával elengedjük azt az illúziót is, hogy az ügyfél előre képes megmondani, mit szeretne és mire van szüksége. Ahogy egy nadrágot is felpróbálunk vásárlás előtt és ha hosszú, felvarratjuk a “kész termék” szárát, ugyanúgy érdemes egy szoftverterméket is időnként “felpróbálni” és szükség esetén alakítani rajta. Ezt teszi lehetővé a korai, rendszeres és sűrű, értékközpontú szállítás és a visszajelzések gyűjtése.

A blogról

Gyakorló tanácsadókként régi tervünk blogot indítani az agilitásról, megosztani tapasztalatunkat, tudásunkat. Eljött az idő. :)

Célunk közérthetően és őszintén írni az agilis módszertanokról és a kapcsolódó területekről, magyarul, a magyar közösség számára.

Akad, aki trendként, divatként tekint ezekre a módszertanokra. Akad, aki vallásként kezeli őket és “hisz” vagy éppen “nem hisz” bennük.

Mi eszköznek tartjuk őket.

Mint minden eszköz, egy módszertan is van, amire alkalmas és van, amire nem.
És mint minden eszközt, ezt is lehet jól és rosszul használni. A siker kulcsa felismerni, hol és hogyan érdemes alkalmazni őket.

Bízunk benne, hogy értékesnek fogjátok tartani írásainkat. A blog sikeréhez természetesen elengedhetetlen az ügyfelek - az olvasók - visszajelzése, ezért bátorítunk benneteket, osszátok meg véleményeteket, kérdéseiteket, javaslataitokat velünk.

Jó olvasást!

Tetszett a bejegyzés? Kövesd a blogot!

blog.hu