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.
Szia Tamás, nagyon tetszik a blogod és különösen tetszik, ahogy a scrum szerepedhez hozzáállsz! Bárcsak mindenki ilyen tisztelettel és alázattal gondolna a munkatársaira! Viszont, kérlek, engedd meg, hogy megosszam a közel 15 éves tapasztalatomat, és bocsi, hogy így ismeretlenül belekotyogok, de szerintem meg pont fontos, hogy mint PO te NE a csapat része légy! Hagyd őket szuverén dolgozni a saját szerepükön: ne avatkozz a csapatszabályok kialakításába, és ne légy ott a retrospektíveken! A PO szerepe a termék vízióját képviselni és kommunikálni, és nem feladata a fejlesztés, mint folyamat vezérlése. A srácok csak úgy fejlődnek, ha szépen végigbukdácsolják önállóan a csapattá válás lépcsőit. Ettől a PO még nem felsőbbrendű, és a csapat sikere az ő öröme is lesz.
VálaszTörlésSzia Attila!
TörlésNagyon köszönöm a visszajelzést. Hozzád képest én még csak tanulom az agilis működést, így minden kritikát szívesen veszek. Értem amit mondasz, viszont nagyban függ a csapat önszerveződő képességétől is, hogy mennyire kell velük lenni. Ha azt látom, hogy folyamatosan nem érjük el a kitűzött célokat, akkor segíteni kell őket. A retrokra direkt nem mentem be, az általad említett okok miatt, de egy idő után maga a csapat hívott be és sokszor jól jött ki, a kibukott problémákat ott helyben meg tudtuk beszélni, kezelni.
Én azt gondolom, hogy ezeket a dolgokat az adott projekt is irányítja egy bizonyos szinten és a felmerült helyzetre reagálva lehet, sőt kell, rugalmasan kezelni.
Mit gondolsz?