A PO, az SM és a Csapat

Megbeszéléseken, emailekben, standupokon sokszor elhangzik a számból, hogy a csapat, vagy PO és a csapat. Egyéb kommunikációkban is gyakran úgy jön le ez a két megnevezés, mint két különálló dolog. És mindig furán érzem magam ettől.

Szakirodalomban is sokan úgy tartják, hogy van a fejlesztő csapat és van mellette külön álló szerepben a product owner. Lássuk az Agile manifesto egyik pontját:

"Az üzleti szakértők és a szoftverfejlesztők dolgozzanak együtt minden nap, a projekt teljes időtartamában."

Együtt dolgoznak, de vajon egy csapatként?

A Lean Startup könyvben is megtalálható az a felállás, amikor a megrendelő (customer) áll az egyik oldalon, a fejlesztő csapat (development team) a másik oldalon.

Tovább nehezíti a megfelelő definíció kialakítását az a kettősség is, hogy a product owner sok időt tölt az ügyféllel (stakeholder), az ő érdekeit is képviselnie kell, a csapat érdekei mellett.

Munkám során előfordult olyan szituáció is, amikor PO-ként több csapat irányítása is feladatom volt. Mondhatjuk, hogy egy csapat tagja sem voltam ebben az esetben. Vagy például a kezdeti időszakban, amikor technikailag még nem voltam olyan szinten, akkor kívülállónak éreztem magam sokszor a fejlesztői beszélgetések közben.

Illusztráció: Werner Nóri

De miért is foglalkozok ezzel?

Mert ezek ellenére én úgy gondolom, hogy PO-ként a csapat szerves része vagyok, amit létrehozunk az közös munka. Ugyanígy a felelősségben is osztozunk. Ha azt mondom scrum csapat, akkor abba PO-ként én is beletartozok. Ez a gyakorlatban annyit tesz, hogy

- részt veszek a csapatszabályok kialakításában

- részt veszek a retrospective-ken

- a csapatot megvédem az ügyféllel és a vezetőséggel szemben, ha szükséges

- a hibák következményeit együtt viseljük

- szorosabb együttműködést és gyorsabb visszacsatolást tesz lehetővé

Illusztráció: Werner Nóri

Ha kívülállóként, üzleti szakértőként viselkednék, akkor csak a stakeholderek érdekeit kellene néznem, és minden felelősség a fejlesztő csapaté lenne. Ettől nem gondolom, hogy könnyebb dolgom lenne, illetve nem hiszem azt, hogy produktívabb lenne a fejlesztés. A fejlesztő csapat szemében nem biztos hogy jól veszi ki magát, ha kívülállónak, csúnyán kifejezve,  felsőbbrendűnek gondolom magamat.

Az igazsághoz hozzá tartozik, hogy a jelenlegi projektem első egy-két retrospective-jén nem voltam jelen, de utána már behívott a csapat és együtt elemeztük ki mi volt a jó/rossz a sprintben és milyen területen tudnánk fejlődni. Sokkal tisztább és egyértelműbb volt így, mintha utána olvastam volna el a confluence-be felvitt jegyzőkönyvet és találgattam volna ki, hogy ki mire gondolt pontosan.

Akad persze ellenvélemény is:

"A potential risk is that with the presence of the PO the daily scrum can revert to a status meeting. Updating the PO rather than collaborating on getting another day closer to the sprint goal." - Duan

Jogos a felvetés, de a scrum master feladata megfelelő kordában tartani a standup eseményt.

Azt is látnunk kell, hogy ha a csapat úgy érzi, hogy a PO nem integrálódott teljesen a csapat napi működésébe, akkor egy idő után a csapat sem fog teljes odaadással részt venni ezen eseményeken, az érték teremtésben és kommunikációs gap jöhet létre.

Ha már szóba hoztuk, akkor beszéljünk kicsit a SM-ről. Neki sem csak az események szervezése, vagy a problémák megoldása, akadályok elhárítása a feladata. Hiszen bizonyos problémák feltárásához szoros kapcsolatban kell lennie a csapattagokkal (lásd 1on1). Nem tankönyvszerű, de az élet adta helyzethez idomulva már előfordult nálunk olyan is, hogy a a fejlesztők a scrum masternek tartottak sprint végi demot.
Kicsit olyan, mint egy család, ahol mindenkinek megvan a maga szerepe, de ha a szükség úgy hozza, akkor segítünk egymásnak, átveszünk feladatokat.

És miért fontos nekem ennyire ez?

Mert az alá/fölé rendelt viszonyban ott van a hibázási lehetőség. Ha pl. a PO az SM-en keresztül kap csak visszajelzést a csapattól.

Összegezve, úgy gondolom, hogy amikor egy projekt kapcsán csapatról beszélünk, abba beletartozik a PO és az SM is, ez az ökoszisztéma adja a teljességet. Az egymástól való függés határozza meg a csapat sebességét, a lefejlesztett funkciók értékét, használhatóságát és végül az ügyfél elégedettséget.

Apró finomságok sprint közben: ábrázolás

Már írtam arról, hogy milyen technikák vannak arra, hogy jobban kontroll alatt tudjunk tartani egy két hetes sprintet, és most pár apró finomságot szeretnék megosztani. Szinte alapvető dolgoknak tűnnek talán az olvasók egy részének triviális, mégis úgy gondolom hasznos lehet megosztani.

Sprint forduló napján az első esemény a demo. Bármennyire is volt tesztelve a lefejlesztett funkció, megírva a user story, mindig akad olyan hiba, ami demon jön elő, olyan funkció, amit a PO rosszul vagy nem egyértelműen fogalmazott meg. Ezeket az észrevételeket a vezető fejlesztő és én is, mint product owner fel szoktam jegyzetelni közben, hogy ne a demo folytonosságát akasszuk meg vele.

Sokszor olyan apróságokról van szó, amiért felesleges a Jira-ba storyt felvinni, így egy flipcahrtra vagy a mágnes táblára írom fel, hogy milyen apró észrevételeket tettünk a review során. Valahogy így:

Azt tudjuk, hogy aminek nincs gazdája, az elég lassan készül el, így még ott helyben felelősöket is rendel a csapat a feladatokhoz. Ami olyan nagyságú feladat, arról hozunk létre új storyt és csak planning után foglalkozunk vele, de amik szükségesek a megfelelő ügyfél demohoz, azokat még aznap el kell végezni. Erre általában a retro és a planning után kerül sor.

Ugyanezt az ábrázoló technikát alkalmazzuk a milestone napján is. Reggel a standup közben felírjuk az adott taskokat, amik nyitva vannak még és a milestone részét képezik. Majd az adott task mellé odaírjuk, hogy ki a felelőse, ad egy becslést a hátralevő időre, illetve megjegyzést is tehetünk oda, ha szükséges. Bár erre ott van a jira is, de az emberi agy mégis jobban befogadja, ha valamiről beszélünk és közben ábrázoljuk is.

Csapaton belüli kommunikáció: hipchat Vs. slack

A csapat legfőbb erőssége abban rejlik, hogy milyen módon képesek a tagok egymással kommunikálni. Ha ez nem megy gördülékenyen, akkor az a teljesítményre is hatással van. Ellenkező esetben viszont olyan rejtett tartalékokra bukkanhatunk, amelyet érdemes kiaknázni.

Kép forrása: themasters.io

Céges gyakorlat nálunk a hipchat használata. Minden csapat létrehoz magának egy szobát és oda kerül bekötésre a jira, a bamboo, selenium pluginek. Mindenről kapunk percre pontos értesítést. Mindenki happy.

A retrokon mégis hétről hétre előjött, hogy nem megfelelő a kommunikáció, elvesznek információk, feltett kérdésekre nem érkezik válasz. Beláttuk, hogy hiába használjuk a hipchatet, a sok értesítő között elveszik a csapat kommunikáció. Scrum masterem ajánlotta, hogy próbáljuk ki a slacket és mire kettőt pislogtam a csapat már használta. A régi hipchat szobát meghagytuk a különböző értesítéseknek, az új slack szobát pedig a kommunikációnak.

Elég volt egy sprint, hogy érezzük a hatását. A retron mindenki dicsérte és pozitívumként jött elő a kommunikáció! Mindenki minden kérdésre választ kapott, mindenki tudta időben, hogy hol van esetleg gond. Ehhez persze szükség volt arra is, hogy a slack értesítő rendszere sokkal jobb (pl. mobilon), mint a hipchat-é, de a plugin értesítők hiánya is jótékony hatással volt.

Néha felül kell vizsgálni az általunk használt eszközöket, hogy valóban a munkát, az érdekeinket szolgálják, vagy éppen gátolják a csapat előre jutását. Merni kell változtatni, újdonságokat kipróbálni, és persze megrertrozni! :-)

És azért persze a slackbe is bekerült egy értesítés. :-)

Nem érünk oda

Az aktuális projektem közepe felé (5-7. sprint) a mérőszámok alapján már láttuk, hogy nem fogunk odaérni az aktuális velocityvel, ahova terveztük, időben. A csapat egy része számára ez nagy teher volt, a másik fele próbálta behozni, de csak kudarc lett belőle a sprintek végére. Az egész csapat stresszben volt, velem együtt, a demot nem ünnepnek éltük meg, a hétvégék is ennek a rossz érzésnek a hatalmába kerültek. Mit tehet ilyenkor egy PO vagy a csapat?

Kép forrása: stressz-m

A becslések nem voltak mindig pontosak, és a 2 hetes sprint nem adott elegendő kontrollt., tehát nem tudtunk időben beavatkozni, hogy sikeres legyen a sprint. A csapat mindig úgy látta, érezte, hogy a sprint végére össze fognak érni a szálak, be fogják hozni a storykat, de valahogy sosem sikerült. Egy-két story kihagyása végülis nem a világvége, de a sprintek számának növekedésével a le nem hozott storyk összege is emelkedett.

A másik probléma, hogy görcsösen ragaszkodtunk minden story elkezdéséhez. Így ha például 12 story volt betervezve a sprintbe, akkor a végén lett 10 darab 90%-ban kész story és két darab el sem kezdett story. De ha arra koncentráltunk volna inkább, hogy befejezett storykat hozzunk le, akkor lett volna 9 darab 100%-osan befejezett story, ami az ügyfél számára is nagyobb értékkel bír, mint több, de itt-ott sántikáló funkció.

Fontos volt valami akció tervet hozni, különben nagy baj lesz a végén. Két eszközt használtunk a sprint közbeni ellenőrzésre.

Meghatároztunk sprint közbenre egy milestone-t, ami a planningen definiált, és az előzetes becslés alapján addigra lehozható storykat tartalmazta. Ezeknek a storyknak a milestone-ra el kell készülnie, ha más külső akadályozó tényező nincsen.

A másik módosítás a feature freeze volt, ami arra irányult, hogy a sprint forduló előtt 1 nappal nincs több új task fejlesztés, hanem a meglévő bugok javítása, az addig elkészült storyk jobbítása volt a cél. Mivel a tesztelő 1 nappal a sprint forduló előtt kapja meg az összes storyt (vegyük figyelembe, hogy jelen esteben komoly függések voltak a storyk között), így kevés idő maradt a funkciók összefüggésében való tesztelésére és a feltárt hibák javítására, sajnos sokszor előfordult, hogy a demo előtt 10 percel még volt merge request.

A milestone beiktatása technikailag annyit jelentett, hogy kedd délután már csak bug javítás volt, új task fejlesztése nem, és szerda reggel tartott egy mini demot a tesztelő nekem.

Ugyan a milestone felfogható pótcselekvésnek a burndown chart helyett, de amíg nem működik jól egy csapat, addig nem ez nem ad pontos visszajelzést, és segít a csapatbak fokúszálni arra, hogy hol tratanak és valóban oda tudunk-e érni a sprint végére, a projekt végére.

A bevezetett intézkedések több kontrollt adtak a kezünkben és az elmúlt 3 sprint tapasztalata alapján elmondható, hogy pozitív hatással volt a csapat teljesítményére, az ügyfélnek szállított értékre.

És hogy ez mennyire agilis? Miért nem álltunk át inkább 1 hetes sprintekre?

A csapat félt attól, hogy a plusz agilis események annyi időt vesznek el, amit jelen szituációban a csapat nem vállalt be.

Mindenképpen szerencsésebb az a fajta hozzáállás, hogy kevesebb, de teljesen jól működő storykat hozzunk le egy sprintben, mint folyamatosan magunk előtt görgetünk minden storyt sprintről-sprintre.

Lehetne olcsóbb?

via GIPHY

Telekocsikázás: a túlóra megmentője, az agilitás halála

Környezetvédelmi szempontból nagyszerű lépés a telekocsikázás, mint rendszer elterjedése. Idehaza ugye az oszkár és a blablacar a legismertebb, de egyre több a saját, főleg munkatársak közötti szerveződés is.

A Virgo kihelyezett irodájában Balatonfüreden dolgozunk, de a legtöbbünk Veszprémből "jár be" dolgozni. Nem egy nagy távolság, kb. 20 perc autóval. Mivel sokan jövünk egy helyről így adja magát, hogy a kezdetekkor bevezettük a telekocsi rendszert, amíg nyár volt és nem kellett reggel a fiúkat az oviba vinni, addig még én is rendszeresen vittem a többieket.

Bár több kritika is érte az irodát, hogy nálunk fél 5-kor kiesik a billentyűzet a kezünkből, ezt betudtuk eddig annak, hogy Pesten más a munkarend (10-18), mint vidéken (8-16). Errefelé ugye nem annyira sűrű a tömegközlekedési infrastruktúra, így ha délután a sofőr már menni akart, akkor bizony az utasok is kénytelenek voltak, a Bakonyba még nem fúrtak metrót...

Eddig ezzel nem is volt gond, viszont egy komolyabb projekt kapcsán már a saját PO bőrömön tapasztaltam, hogy milyen hatással van a telekocsikázás a teljesítményre:

- be nem fejezett story

- elfelejtett commit

- bug

- csökkenő velocity

Hogy miért? Mint fent említettem, ha a sofőr indul, akkor menni kell. Ha egy csapaton belül lenne az egy autóhoz tartozó társaság, akkor nem lenne ilyen gond. De jelen esetben 2-3 csapatról van szó, sőt az épületben dolgozó másik cégből is van, aki a munkatársaimmal jár dolgozni, tehát ő hozzá is kell igazodni.

Mi a megoldás?

Jelen esetben most annyit tettünk csapaton belül, hogy kijelöltünk a sprinten belül két milestone-t és ahhoz tartozó 2 napot (értelemszerűen az egyik a demo előtti nap), amikor addig nem megyünk haza, amíg nincs minden vállalt story kész (ha az időn kívül más akadályozó tényező nincsen). Ezen a napon mindenki így készül, külön autóval jön.

Logolni vagy nem logolni, ez itt a kérdés

Számomra az egyik legkedveltebb része az agilis módszertannak, hogy a csapat saját maga határozza meg azt a szabály rendszert, amiben dolgozni szeretne sprintől sprintre. Ha a közösen megalkotott szabályok mégsem bizonyulnak megfelelőnek, akkor a csapat a retrospective keretében módosíthat rajta, elvethet egyet, hozzáadhat újat a listához. Jelenlegi csapatom egyik ilyen kitétele volt, hogy nem kötelező a logolás, vagyis nem fognak logolni. (ez amúgy céges szinten is sokszor vita tárgya)

Egy nagy projekt kezdetekor, tele lelkesedéssel és ekkora kihívással szemben állva PO-ként erre simán áldásomat adtam, hiszen úgysem ezen fog múlni egy sprint sikeressége. És valóban, nem is volt ezzel semmi gond, planningen megvolt a becslés és kész, jobban fókuszáltunk a SP-kra.

Az első problémák most adódtak, amikor realizáltuk, hogy csúszunk a projekttel és tudni kellene, hogy milyen sebességgel halad a csapat (óraszámmal) és a hátralevő taskok mennyi idő alatt hozhatóak le. Nem mindenki logolt, aki logolt az is össze-vissza, így nincs a kezünkben egy pontos mérőszám, így a jövőre vonatkozó kalkulációnk is csak becslés lehet. Meglepően alacsony napi óraszám jött ki, és nem csak a logolás miatt, hanem a lehozott storykra adott becsléseket összeadva is. A csapat elé tárva ezt az értéket ők is meglepődtek és realizálták, hogy ez valóban kevéske.

Úgy látszik a boardból, hogy rákapcsoltak, kíváncsi leszek ebben a sprintben mennyi lesz a vége.

Akcióként hoztuk, hogy mostantól mindenki pontosan logol a projekt végéig.

A jövőre vonatkozó tanulság, hogy sajnos nem mindenben lehet engedni a csapatnak, a mérőszámok fontosak a projekt egésze alatt. Megfelelő becslés, és következetes logolás mellett időben észre lehet venni a csúszást és időben reagálni, beavatkozni.

Tippek logoláshoz:

- backend és frontend külön subtaskra logoljon

- ha Jira-t használsz, akkor nézd át az exportot, mert nem mindig számol rendesen

- automatikus log tool használata

Edzés

Kedves munkáltatóm által lehetőségem van ingyen sportolni, így hosszű kihagyás után végre megint járok edzeni. Bár otthon is volt fekpadom, meg súlyzókészletem, de Kondo: Rend a lelke című könyve alapján igyekszünk a felesleges, évek óta nem használt tárgyaktól megszabadulni. Először nehéz, de a végeredmény felemelő, hogy kevesebb tárgy fogságában élsz.

Na, de vissza a sportra. Szóval elkezdtem újra edzeni járni. Azt tudni kell rólam, hogy nagyon vékony testalkatú vagyok, amihez magasság is jár, így elég viccesen nézek ki a kigyúrt emberek között. De nem nagyon érdekel, hiszen ők is elkezdték valahol, senki sem születik Terminátornak. :-) Sokak számára lehangoló és hamar feladják, amikor mellettük 80-100 kilóval nyomnak fekve emberek, és ő még a 10 kiló alatt is nyög. Ez nagyon rossz hozzáállás. El kell kezdeni kis súlyokkal, kitartóan, alázattal, hétről hétre erősödve csinálni, fejlődni.

Ugyanígy van a munkában is. Még ha jók is vagyunk a szakmánkban, mindig van kitől tanulni. Kérdés, hogy hajlandóak vagyunk-e a kritikát meghallgatni, értelmezni, és egyre nagyobb súlyokat magunkra pakolva fejlődni. Sokat segíthet ebben, ha van egy mentor (nekem szerencsére van, több is), akitől szakmai trükköket le lehet lesni, akinek a tapasztalataiból tanulva nekünk nem feltétlenül kell ugyanazokat a hibákat elkövetnünk.

Mindez persze nem fog menni megfelelő kitartás nélkül.

Felesleges sorban állás

Minden alkalommal jót nevetek magamban, amikor bejelentik a hírekben mint valami óriási dolgot, hogy 2 Ft-tal emelik a benzin árát és mindenki rohan tankolni, akár negyed óráig is sorba állva. Ha egy kicsit is tovább látunk a bejelentés manipulatív voltán, akkor számoljunk.

Miközben ott várakozik a sorban, leálltja az autót, újra indítja a motort, 5 méterrel arrébb gurul a másfél tonnával, majd tovább várakozik, kicsit megint előbbre gurul és így tovább. Ahogy nőztem, legalább 6-7 kocsi szokott így várakozni egymás után. Átlagos autó üzemanyagtartályát véve, ami mondjuk 50 liter, 2 Ft/liter kedvezményél 100 Ft megtakarítást jelent egy tankolás. Big deal! A sorbanállás alatt legalább fél liter elfogy, ami mai árakkal számolva 150-200 Ft. Megérte. Több benzint elpazarol, mint amit megspórol. És akkor az ott töltött semmibe veszett időről nem is beszéltem.

Ugyanilyen pazarlás olyan funkciók lefejlesztése, amit senki nem fog használni, vagy nem szolgál üzleti értéket. Sokszor tapasztaljuk azt, hogy egy ügyfél bele van szerelmesedve egy funkcióba vagy annyira vakon hisz valamiben, hogy mindenáron át akarja tolni annak fejlesztését a csapaton.

Mit tehetünk mi PO-k ilyenkor? Több módszer is a segítségünkre van.

5 whys

Használjuk a 5 whys technikát az adott funkcióval kapcsolatban és hamar ki fog derülni, hogy tényleg van értelme a kívánt funkciónak vagy nincs.

Üzleti érték

Puszta számokkal határozzuk meg, hogy mekkora üzleti értéke van az adott funkciónak, miben segíteni a ROI, a bevétel növekedését.

Konkurencia vizsgálat

Természetesen nem szentírás a konkurencia, de jó kiindulási alap lehet, ha az előnyben lévő versenytársnál sem használják az adott funkciót. Mivel én is voltam ügyfél szerepben, így jól tudom, hogy nehéz meggyőzni valakit annak az éllentétjéről amiben nagyon hisz. 

Viszont product ownerként az a feladatunk, hogy segítsük az ügyfelet, tudjuk nemet mondani neki, ha szükséges, és egy olyan termék létrehozásában támogassuk, ami valóban nyereséget fog termelni neki.