Több Product Owner egy projekten?
Ideális esetben agilis projekten egy Product Owner tartja kézben a követelményeket és kommunikál az összes stakeholderrel. A szerepkör betöltésére a legtöbbször elegendő egy ember, sőt célszerű is, ha egy kézben összpontosul a követelmények beszerzése és Backlog kezelése, de vannak olyan esetek, amikor többen látják el ezt a feladatot egy projekten, vagy több skálázott projektnek kell együttműködnie.
Most az előbbi esettel fogunk foglalkozni, bemutatjuk mikre kell ügyelni egy olyan nem skálázott projekten, ahol több PO dolgozik.
Először nézzük az elméletet, mit mond nekünk a Scrum Guide:
“Több Scrum csapat gyakran dolgoznak azonos terméken. Egy termék Backlog írja le az elvégzendő munkát a fejlesztendő termékhez” — áll a Scrum útmutatóban
Nézzük tovább az ajánlásokat:
“A Product Owner egy személy, nem egy bizottság.” — Scrum útmutató
Egy termék Backlog = Egy Product Owner, ebben kifejezetten nem megengedő a Scrum útmutató, tehát így felmerül a kérdés, miért írunk cikket egy elméletben nem létező témáról?
A gyakorlat viszont mást mutat, a cégek által implementált agilis működésekor előfordulhat a projekteken amikor több dontéshozót jelölnek ki Product Ownernek, mivel már találkoztunk meglepően jól és rettentő rosszul működő példákkal, megosztjuk veletek milyen sémákat érdemes betartani.
1. Elkülönített felelősségi körök Product Owner szinten
Kifejezetten segít a helyzeten, amikor nem egy területért felelnek a Product Ownerek, így kevésbé alakulhat ki vitás helyzet közöttük. Amikor hasonló területért felel két ember, valójában osztott felelősség miatt ketten nem felelnek érte. Ilyen területek lehetnek:
- Üzleti felelős
- Jogi megfelelőségért felelős
- Technikai személy
- Backlog felelős
- UI / UX felelős
- Teszt adat felelős
2. Kiegészítő szerepkör: Business Analyst
Kifejezetten jól tud működni egy üzleti elemző azokban a csapatokban, ahol több Product Owner is jelen van a csapat életében. Ilyenkor az adott csapatra nézve mérlegelve kell eldönteni a Product Ownerek mennyire legyenek bevonva a csapat életébe.
Általánosságban az üzleti elemzőt érdemes Proxy PO-ként használni, így elfedjük a bizonytalanságot a fejlesztő csapat elől, de a backlog előkészítő meetingeken érdemes ha jelen tud lenni az egész csapat.
3. Felkészítő Jour-fixe, a nagyok harca
Hasonlóképp, mint amikor gyerekként apu és anyu otthon veszekednek, a fejlesztő csapat előtti nézeteltérések is károsak, ebben egyet érthetünk. Ezért érdemes egy előszűrést tartani, a Prouct Ownerek, Üzleti elemző és Scrum Master társaságában, hogy már egy véleményen legyenek a döntéshozók.
Külön érdemes az idő rövidsége miatt valamilyen módszertant alkalmazni a felmerülő témakörökre, használjatok színkódolást, kategóriákat, jelöljétek meg a felelősöket akinek készülnie kell, hogy ne kelljen sűrűn follow-up meetinget szervezni.
4. Ha nem jól működik, root-cause analizáljuk
Legvégső soron fontos mindig kielemeznünk a helyzetet, mi okozza a problémát. Root-cause analizáláskor próbáljunk leásni a probléma gyökeréig, erre vanak kifejezetten jó technikák, amivel azonosíthatjuk melyik problémát érdemes megoldani először. Egyszerű példának okáért használhatjuk a probléma fánkot.
Nyilván a cikkünk azt feltételezi, hogy már benne vagyunk egy olyan szituációban, ahol több Product Owner is dolgozik a projekten. A legideálisabb ezt a helyzetet kerülni, hogy egy személyű PO-val dolgozhassunk.
De ha már benne vagyunk egy kevésbé ideális szituációban, próbáljuk meg a legjobbat kihozni belőle.
“Amennyiben változtattok a csapat működésén, ne több dolgot egyszerre, hogy mérhető maradjon a hatása.” — Ezt mi tanácsoljuk
Ha találkoztok helyes mintával a témában, kérünk írjátok meg nekünk, hogy működik a csapat és szerintetek mi az erősségetek, ami miatt egy jól funkcionális csapatot tudtatok kialakítani több Product Owner társaságában.