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.

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.

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.

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:

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:

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? :)