Miben segíthetünk?

Oktatás

Agilis szoftverfejlesztés, projekt management, vezetői skillek és marketing oktatások a te és céged igénye szerint.

Ügynökség

Marketing ügynökség, online és offline marketing, e-mail marketing, SEO, social tartalom gyártás, hirdetés beálltás, nyomdai munkák.

Tanácsadás

Projektvezetési tanácsadás, akár induló, folyamatban lévő, illetve retrospective-ként lezárt projekttel kapcsolatban.
info@agile.hu

Több Product Owner egy projekten?

The Agile Agency > Agile  > Több Product Owner egy projekten?

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.