A csapat sorra bukta a sprinteket, egyre frusztráltabbak voltak, panaszkodtak, hogy nem egyértelmű, mi alapján sikeres vagy bukott a sprint. Felvetették, hogy pontosan definiálható, objektív kritériumok alapján határozzák meg a sprint sikerességét: “Akkor legyen sikeres a sprint ha a feladatok 90%-át teljesítjük. Így teljesen egyértelmű lenne, hogy hogy állunk és jobban el tudnánk érni a célt.”

Valami nyilvánvalóan nem működött jól, a javasolt megoldásuk viszont csak tüneti szinten hatott volna. A valódi sikerhez ugyanis szükséges, hogy a csapat kapcsolódni tudjon a feladat értelméhez, és ne vesszen el a to-do listák pipálásában.

Feladatok vs. Eredmény

Minden sprint elején meghatározzuk a sprint célját, ez egy “idea”, ami segít megragadni hogy “Miért van erre a sprintre szükség? Mi az a tágabb üzleti érték amit szeretnénk megvalósítani? Mire van igazából szüksége az ügyfélnek / felhasználóknak?”. Ezt a magasabb ideát konkretizáljuk user story-kon, projekt backlog-on keresztül, és végül ezek alapján vállal a csapat egy konkrét sprint backlog-ot. Így egyértelmű, hogy mik azok az eredmények, amiket a sprint végén PO-ként a csapattól várunk (Output) és az is, hogy miért fontos ez (Outcome).

Forrás: Output vs Outcome vs Impact — Crisp’s Blog

Gyakori PO hiba, hogy az igény (outcome) dimenzióját nem tudjuk jól átadni. Ez elidegeníti a csapattagokat a munkájuk értelmétől, csak a feladatokat látják, de a mögöttük lévő miérteket nem. Ebből ki tud alakulni egy ördögi kör: a csapat időnként “értelmetlen” módon oldja meg a feladatokat, PO-ként elégedetlenek vagyunk az Output-al, ezért még pontosabb specifikációt adunk, akár több oldalnyit is story-nként, viszont így méginkább elveszik a munka értelme, és ami nem volt eléggé specifikálva ott félre csúszik a fejlesztés.

A sprint értékelésénél fontos a feladatok és az eredményesség megkülönböztetése.

Szuper a csapat ha leszállított minden vállalt story-t. PO-ként viszont nem csak ezt értékeljük, hanem képzeletben bele bújunk az ügyfél bőrébe és megkérdezzük magunktól: “Mennyire értékes amit létrehoztunk? Erre van valóban szüksége az ügyfélnek? A csapat munkájára elköltött pénz megérte azt, ami a folyamat végén létrejött?” 

Ha nem sprintekben dolgozunk akkor is érdemes mindezt megtenni. Ekkor még nagyobb PO-ként a felelősségünk, hogy megfelelő ritmusban tűzzünk ki célokat a csapattal, értékeljük az elvégzett munkánkat és annak eredményét.

Szempontok egy story megvalósításának megítéléséhez

A sprint sikerességének megítéléséhez kezdjünk az építőkockák szintjén: Story szinten van pár bevált eszközünk, ami segít az Output leszállításának sikerességét megítélni:

• Az elfogadási kritériumok,
• A “Kész” definíciója (pl. Demózható, Tesztelt, Integrált, Telepített)

mind azt segítik, hogy objektíven megítélhető legyen elkészült-e a vállalt story vagy nem.

Sok finomabb szempont is van, amit érdemes mérlegelnünk, hogy egy Story tényleg kész-e van, jó-e úgy ahogy van:

• Illeszkedik a kinézete a rendszerünkbe?
• Elég gyors?
• Az üzleti domain-nek megfelelő szavakat használjuk?
• Elég jó a felhasználói élmény (UX) összessége?

Ezekben a kérdésekben is érdemes törekedünk arra, hogy meg tudjuk fogalmazni a követelményeket, legalább irányelvek szintjén, vagy ezt akár be is építsük a rendszerünkbe, folyamatainkba. A UX guide, performance budget, az üzleti domain szótára, egy design system mind segíthet ebben. A konkrét, írásban meglévő guide-ok mellett a mi és a csapat kapcsolatának fejlődésével egyre nő az implicit közös megértés. Akkor is értjük egymást, ha nincs minden pontosan megfogalmazva és leírva.

Szempontok a sprint sikerességének megítéléséhez

PO-ként feladatunk, hogy átvegyük a csapat által szállított eredményt és mind objektív, mind szubjektív értékelés szerint visszajelezzünk a sprint (vagy ha nem sprintekben dolgozik a csapat, akkor az elmúlt pár hét) sikerességéről. 

Elkészültek a vállalt feladatok (Output)?

• Elkészültek-e azok a jegyek, amikben a sprint elején megegyeztünk a mi “Kész” definíciónk szerint?
• Változott az igény, a sprint scope a sprint közben? Mikor? Mennyit? Mekkorát?

Eredmény és üzleti érték (Outcome)

• Az elmúlt sprintben mennyi üzleti értéket állítottunk elő? Ez több vagy kevesebb mint a csapat költsége (bérekkel, irodával, mindennel)?
• Mennyi új követelményt / feladatot fedeztünk fel a sprint közben? Hogyan hat ez a projektre?
• Mennyire látjuk tisztán a kockázatokat, kérdéseket?
• Mennyire tudtunk kis kísérleteket futtatni a kockázat csökkentésére? Vagy túl drágán jöttünk rá, hogy nem teljesült egy feltételezésünk?
• A megrendelő értékesnek ítélte az inkrementumot, amit mi és a csapat együtt hoztunk létre?
• Mennyit tanultunk a kísérletekből, próbálkozásokból amiket a sprintbe terveztünk? (pl. Milyen kockázatokat csökkentettünk, hipotéziseket validáltunk, lehetőségeket zártunk ki?)
• Mennyi technológiai adósságot halmoztunk fel? Vagy éppen növeltük a fejlesztési kapacitásunkat?

90%-os példa a valós vállalásról

Egy pillanatra térjünk vissza a cikk elején felvetett megoldáshoz, a 90%-ról és hogy ez miért csak tüneti megoldás. A csapat a sprint elején vállalást tesz, ennek teljesítése a siker objektíven értékelhető része: teljesítettük vagy nem teljesítettük. Ha ezen felül a csapat másik objektív mérőt is meghatároz, hogy mennyi százaléka az elvégzett feladatoknak jelenti számukra a sikerességet, akkor két ellentmondó vállalás van: egyszer 100%-ot “vállalunk”, aztán meg azt mondjuk, hogy 90% is már siker. Ezzel éppúgy zavart keltünk, mint amikor nem tiszta, hogy mit értünk az alatt, hogy valami “Kész”. Ilyenkor jobb ha kimondjuk, hogy a 90% a vállalás. Ha akarunk a vállalás fölé is kitűzni célt, akkor nevezzük ezt a +10%-ot stretch goal-nak. Nagyon más érzés ugyanazt a 90%-os eredményt a két “vállalás” nézőpontjából értékelni:

• 100% vállalás – 10%: “Siker, mert végülis a vállalásunk 90% meglett.”
• Vállalás + strech goal: “Siker, mert megcsináltuk amit vállaltunk!”

Még nagyobb a különbség, ha esetleg még többet is elértünk mint amit vállaltunk:

• 100% vállalás – 10%: Nagy siker, a vállalásunk 100%-át teljesítettük, nem csak 90%-ot!”
• Vállalás + strech goal: “Nagy siker, a vállalásunk felett még X és Y is meglett!”

Lehetséges, hogy a csapat teljesítette a sprint vállalását, de PO-ként mégis kénytelenek vagyunk kimondani, hogy sikertelen volt a sprint?

Ritkán, de igen!

Ha valamiért a sprint utolsó napján ébredünk rá, hogy nincsen szükség mindarra, amin az elmúlt hetekben dolgozott a csapat. Talán bele lehet tenni a termékbe amivel most elkészültünk, de az új információk fényében már nem érte meg elkölteni rá azt az összeget, amennyibe a csapat egy sprintje kerül a cégnek.

A résztvevők hibáján kívül előfordulhat, hogy pl. ekkorra futott be egy kritikus információ a megrendelőtől, vagy visszajelzések az ügyfelektől, vagy olyan külső körülmény változott meg, ami miatt a terméket más irányba szükséges fejleszteni.

Az is lehet, hogy az üzleti igény megváltozott, de a PO-ként erre nem reagáltunk elég gyorsan, nem kommunikáltuk ezt a csapat felé, vagy nem úgy kommunikáltuk, hogy a csapat megértse és megfelelően irányt váltson.

💡 Például a csapat egy új hitelkonstrukció fejlesztésével készült el és már csak az élesítés van hátra, amikor az MNB a COVID-19 járvány miatt átírja a hitelpiac szabályait. Ebben az esetben mindenki, az ügyfél, PO, csapat, tökéletesen végezte a munkáját, mégsem történt üzleti érték teremtés.

Ha egy hiba miatt nem teremtettünk értéket a termékben, még menthetünk a helyzeten, ha legalább tanulunk a hibából, és jobb csapattá / PO-vá válunk. Ennek hiányában viszont teljes a kudarc.

Itt az a fontos, hogy merjük kimondani, szembenézni vele, ha valami nem teremtett értéket. PO-ként a legjobb, amit ilyenkor tehetünk, hogy a saját hibáinkat, felelősségünket vállaljuk a csapat felé. Példamutatásunkkal építjük azt a kultúrát, amiben a többiek is úgy érzik majd, hogy szabad, (sőt akár menő is) a hibáinkat felvállalni. Ez nyitja meg a lehetőségét, hogy a retrón tanuljunk a hibáinkból.

A sprintértékelő visszajelzésünk célja az értékteremtő képességünk fejlesztése

Forrás: https://blog.crisp.se/wp-content/uploads/2013/08/20130820-What-is-Agile.pdf

A szubjektív és objektív szempontok nem statikusak, a cég a csapat, változnak a csapat, a PO és az ügyfél kapcsolatának fejlődésével.

Ügyfél-kapcsolat

Egy kezdő ügyfél-kapcsolatnál még nem az ügyfél számára értékes módon fejlesztünk, hanem a saját megszokásunk, konzerveink szerint. Alig értjük még, hogy mi is tényleg fontos, értékes neki és a megszokásaink lendülete visz minket, amit nehéz megváltoztatni. Ilyenkor lelkesen lapátoljuk sorra agyag tömböket a teherautóra, és nem értjük miért nem elégedett az ügyfelünk? Hol veszik el az értékteremtés?

Az ügyfél felé irányuló kíváncsiságunk és a célhoz való kapcsolódásunk adja azt a nyitottságot és energiát, amivel ki tudunk lépni a rutinból.

Figyelünk a visszajelzésekre, a sprint review-kon, vagy ha ügyesek vagyunk, akkor már az ügyféllel közös tervezéseknél is észrevesszük, hogy neki mi a fontos. Sokat számít, hogy a megfelelő kérdéseket tegyük fel, amivel fel tudjuk fedezni azt, amit talán még az ügyfél maga sem tud a saját igényeiről. Segít, ha észrevesszük és kérdéssé formáljuk a saját feltételezéseinket. 

Veszélyt jelentenek azok a helyzetek, amikor nem tudjuk, hogy valamit nem ismerünk, így nem is tudjuk, hogy fontos lenne rákérdeznünk. Ezen segít, ha konkrét üzleti példákon keresztül beszéljük át az igényeket, a konkrétumok szintjén tudnak ezek a meglepetések hamar kibukni.

Ha az output nem is feltétlen növekszik, az értékteremtésünk fejlődik, ahogy egyre jobban értük az üzleti igényeket, hogy mi jelent értéket az ügyfélnek.

Csapat és PO

Ahogy fejlődik PO-ként a kapcsolatunk a csapattal, egyre több mindent tudunk objektíven meghatározni. Újraolvassuk és tanulunk a story-kból: mi hiányzott, mi volt félreérthető, mi volt túl-specifikálva? Megtanuljuk egyre jobban leírni a feladatokat, és lefektetni az elvárásokat saját munkánkkal szemben (pl. Design és UX guide).

Ahogy egyre inkább tudunk építeni a korábban már bevált gyakorlatainkra, megoldásainkra, úgy tud a figyelmünk és érzékelésünk azokra a régiókra irányulni, ahol még fontos kísérleteznünk. A jó gyakorlataink beépülhetnek implicit a szokásainkba, vagy explicit leírhatjuk őket belső ajánlásokba. Ha ezek nem csak megszokások, hanem le is írjuk őket, akkor sokkal rugalmasabban tudunk gondolkodni, változtatni rajtuk, mert megfogható a közös alap, van mire rámutatni, amikor változtatásról beszélünk.

„Ha valaki sikeres akar lenni, akkor hibái számát meg kell dupláznia.” (Thomas J. Watson, az IBM alapítója)

Így üzleti értéket jelent az is, ha a csapat fejlődött, még akkor is, ha ez nincs forintosítva a backlog-ban. Ugyanez igaz az olyan fejlesztésekre is, amik végül nem használhatóak üzleti szempontból.

Ha megfelelően gondolkodunk csapatként és PO-ként a tanulás értékéről, akkor sikeresnek ítélhetünk olyan sprintet is, ahol bár rövidtávú direkt üzleti értéket nem tudtunk teremteni, de stratégiai szempontból értékes felfedezést tettünk a piacról,  igényekről, vagy belső működésünkről.

Például, sikeres kísérlet negatív eredménnyel, amikor a google új formájú keresőgombokat próbál ki, és az A-B teszten kiderül, hogy ettől csökken a keresések száma. Ettől még fognak tovább kísérletezni a gomb formákkal.

A PO értékelése input a következő retróhoz

A PO-ként a sprint értékelése során érzékenynek kell lennünk arra is, hol tart a csapat az agilitás terén és milyen visszajelzésekkel segíthetjük a fejlődését. A csapatnak erős konfrontációra vagy éppen siker érzetre van szüksége a fejlődéshez?

A retrón lehetőség nyílik beszélni arról, hogy a milyen szempontok alapján értékeltük a sprintet és miért. Ezért történik először a review (adatok és tények áttekintése), amit a szubjektív értékelésünk és visszajelzésünk követ (az objektív adatok értelmezése üzleti érték szempontjából), ami átvezet a retróba (Mit jelent az nekünk?). Sok csapattal találkoztunk, akik ezt a lépést kihagyták, megálltak a demo-nál, és amiből így szinte semmit sem emelnek át inputként a retróba, majd a legközelebbi projektnél mindent kezdenek elölről anélkül, hogy tanultak volna a tapasztalásaikból.