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
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.
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.