Projekty, všade samé agile projekty

​Menšie firmy sa potrebujú veľa obracať, aby dokázali prežiť. Najčastejšie sa

pri mentoringu stretávame s tým, že berú veľa zakázok a pracujú tak na viacerých projektoch súčasne.

S týmto javom bojuju aj väčšie spoločnosti.  Najčastejšie firma chce využívať kapacitu ľudí naplno. Jednoducho prečo by mali iba sedieť keď je na čom pracovať. Ak nie je, niečo sa nájde.

So zavedením agile prichádza dôležitá zmena. Jeden produktový vlastník pre tím.

Hmm, ale čo ak máte aktívne viaceré projekty súčasne? Ako sa PO rozhodne čo je dôležitejšie? Veď všetci chcú​ všetko a hneď.

Product Owner satelitom

V tíme ABC sa produktový vlastník rozhodol, že bude obiehať projekťákov a pravidelne zozbiera požiadavky.  Aj sa to dobre začalo, niekoľko týždňov to aj fungovalo. Čoskoro sa však kalendáre rozsynchronizovali a PO začal mať v backlogu medzery, ktoré mu projekťáci dopĺňali priebežne a na poslednú chvíľu.

V aktuálnom sprinte sa menil rozsah. Tím považoval planning za zbytočný, veď obsah sa aj tak neustále menil. Projekťáci sa hnevali, lebo ich projekty meškali. Nemohli sa spoľahnúť na sľuby PO.

A pritom ten chudák sa tak snažil. Jednoducho depka.

Product Owner centrom galaxie

Tím ZYX išli na to inak. Product Owner si povedal, že bude pre neho strašný waste obiehať stakeholderov dookola. Zistil, že nebude mať čas na detailizáciu, priorizovať a hlavne na tím a produkt.
A tak si nastavil stretnutia so stakeholdermi inak.

Podobne ako sa tím stretáva na planningu, všetci naraz, aj stakeholdermi sa začali stretávať všetci naraz. Najprv na preplannigu sprintu. Všetci v ten istý deň raz za šprint. Každý si doniesol svoje požiadavky. Musel ich mať už zoradené podľa dôležitosti pre klienta a business hodnoty pre firmu. Na stretnutí stakeholderi si porovnali potreby a dohodli si možné poradie požiadaviek.

Tento rad požiadaviek sa v ďalšom týždni dostal na preplannig tímu, kde sa členovia vyjadrili k realizovateľnosti, stave pripravenosti požiadaviek a prípadnému riziku. Nakoniec odhadli požiadavky s pomocou story points.

PO zapracoval feedback do aktualizovaného poradia. Podľa velocity timu potom vybral požiadavky, ktoré tím   pravdepodobne  ani nestihne  dokončiť.

Tretí týždeň sprintu sa opäť stretol so stakeholdermi, kde im ukázal, čo všetko je možné spraviť. Stakeholderi sa medzi sebou dohodli kto komu pustí kapacitu, ak to bolo potrebné z pohľadu realizácie a biznis priority.

Čo si to vyžaduje?

Pravidelnú komunikáciu a disciplínu. A práve preto to funguje.

1. Každý zo stakeholderov vie, že raz bude potrebovať väčšiu kapacitu aj on.
2. Vedia sa pochopiť navzájom, pretože majú rovnaké problémy aj ciele, len v iných projektoch.
3. Stakeholderi vďaka priebežnému stretávanie sa s produktovým vlastníkom vedia prispôsobiť svoje plány a vopred ich komunikovať s klientmi.
4. Tímu sa dostávajú na nasledujúci šprint planningu už požiadavky, ktoré poznajú a rýchlejšie ich rozbijú na konkrétne úlohy.
5. Navyše sa zaoberajú tým, čo sa v šprinte dá stihnúť.
6. Produktový vlastník sa má možnosť koncentrovať sa na  detaily,  pretože nemusí pripraviť  strašne veľa  a vo všetkých projektoch.
7. Ak sa niečo zmení, Produktový vlastník vie zvolať stakeholderov aj na kratší call.
8. Stakeholderi sa vedia vyjadriť k riešeniu aj priebežne a podľa výsledkov prispôsobiť svoje požiadavky.
9. Nutnosť pripraviť ďalšie požiadavky ich prinúti sa stretnúť s klientom.
10. To prinúti klienta rozmýšľať v iteráciách a zamyslieť sa nad tým čo ďalšie je dôležité.

Čo si to však vyžaduje?

Povedať si business prioritu jednotlivých projektov.

Chcieť sa pochopiť. A preto mať projektové ciele prepojené s firemnými.

Povedzte si na rovinu. Entropiu je treba znižovať. Iba tak sa chaos udrží v rozumnej miere.

Nie každý projekt  je rovnako dôležitý. A niektorých sa treba zbaviť čo najskôr. Aby nežrali kapacitu a neblokovali prietok tímu a väčšej hodnoty.