scrumster

Az ügyféllel való együttműködés nem opcionális

Avagy hogyan ne utáljuk meg őket?

2019. május 24. - nagyeszteranna

Az agilis szemlélet kardinális része, hogy az ügyféllel való együttműködés fontosabb, mint a szerződés fölötti folyamatos egyeztetés, veszekedés, játszmázás, zsarolás, sarokba szorítás.

Igazán egyik sem könnyű feladat, viszont a vélekedés az, hogy előrébb visznek, ha az együttműködés jóságán próbálunk módszeresen dolgozni, mintsem apróbetűs kiskapukat bogarászni a szerződésben azért, hogy rá tudjuk tolni a felelősséget a másik félre, ha rosszul áll a projekt szénája.

adults-analyzing-brainstorming-1385633.jpg

Fontos embereknek tűnő alakok olvassák mélységes együttműködésben a blogomat
Forrás: https://www.pexels.com

Node, azért van remény. Ha az érintettek felismerték, hogy az energiáikat inkább a túloldal megismerésére, és a velük történő közös munka fejlesztésére kell fordítani, akkor abból még lehet sikersztori.

Eddig általában olyan projekteken vettem részt, ahol a Product Ownert/Business Analyst-ot a kivitelező cég adta, mivel a megrendelőnél nem volt meg a tudás, hogy módszeresen tervezzen, userstory-kat írjon, és ideje nagy részét a fejlesztő csapattal töltse. Így a Product Owner szerepe megoszlik: a megrendelő ismeri az üzleti folyamatokat, a környezetet, a felhasználóit, övé a büdzsé, így a döntés is. A kivitelező "PO"-ja pedig inkább tanácsadó, ismeri a módszertant, tudja, hogyan kell értékvezéreltem haladni, a fejlesztőkkel együtt dolgozni, ő írja a feladatokat. (Persze ez a felállás könnyen változhat, és ez nem éppen az ideális működés.)

Így tehát nem nehéz belebotlani egy olyan projektbe, ahol 5-10 embert is kitesz az a csapat, akik a fejlesztő csapat által végzett munka értékének maximalizálásáért dolgoznak, összeadva a megrendelő és a kivitelező embereit. Kellő tudatosság nélkül a két oldal hamar elfelejtheti, hogy a cél közös, mégpedig a jó termék készítése (értsd: amivel a felhasználó, a fejlesztő, a megrendelő, a kivitelező cég tulajdonosai, és az érintett menedzserek is elégedettek). Ez pedig egy idő után elviselhetetlen fájdalmakhoz, értelmetlenségekhez és lassú halálhoz vezet. Nincs rá statisztikám, de esetenként károsabb lehet, mint a dohányzás.

Vannak praktikák, hogyan lehet javítani a közös munkán. Fontos például, hogy rendszeresen legyen egy fórum, amikor a két fél arról beszélget, hogyan tudnának jobban együtt dolgozni. Visszajelzéseket adni egymásnak, időről-időre tisztázni, hogy kinek mi a feladata, hogyan tud a legjobban hozzátenni a közös munkához, illetve, hogy mivel akadályozza legjobban a közös munkát. Hiszen igazi csapatként kell együtműködniük, akik ugyanazért  a célért dolgoznak. Az is hasznos tud lenni, ha a közösen meghozott szabályok, működési módszerek rögzítve vannak, és gyakran felül vannak vizsgálva. Továbbá ha ismerjük egymás elvárásait, és tisztázzuk, mi mit tudunk nyújtani. Megfeszített munkával pedig egy őszinte légkör tud kialakulni, ahol hamar felszínre tudnak kerülni a rossz érzések.

Hiba az, ha akkor kezdenek el ezekről beszélgetni, amikor már mindenkinek tele van a hócipője a másik oldallal. Ha nem módszeresen beszélgetnek, hanem ímmel-ámmal, hébe-hóba. Rendszeresség kell bele és következetesség, ezek nélkül legalább olyan értelmetlen, mint úgy sorozatot nézni, hogy mindig csak az évad záró részét nézed meg. Nem fogod érteni, igazából mi történik.

Egy közös retró fabulája

Az egyik megrendelőnk oldaláról szerettek volna egy retrót, amikor is megbeszélik, hogy "hogyan tudunk hatékonyan jól együtt dolgozni". Itt a felállás az volt, amit fent vázoltam, kicsit többen, 15-20 ember dolgozott a Product Backlogon.

Mivel sok tüske született már a béna együttműködésből fakadóan, ezért azt gondoltuk, hogy kevésbé az elmúlt hónapok történéseire kellene fókuszálni, mert az könnyen mehet át a sárdobálásba, hanem inkább a közös együttműködés alapköveit kellene lehelyezni. Ahányszor megkérdeztem a megrendelő oldali kapcsolattartót, hogy mi lesz a retró célja, mindig bullshitnek tűnő igéket kaptam. Ezt kihasználva ajánlott egyik scrummaster társam egy technikát.

Az én implementálásomban a módszer menete, hogy együtt meghatározzuk a csapat egy közös szándékát. Azt a szándékot, amiért az emberek eljöttek erre a kellemes pár órára. Ezután mindenki megfogalmaz kulcseredményeket, amikben ez a szándék meg tud valósulni, ezután pedig kisebb csapatokban a három legfontosabb eredményhez siker és bukás indikátorokat rendelünk, amikből látszódik/hallatszik/érződik, hogy az eredmények megvalósulni vagy elbukni fognak. Példa: ha a szándékom az, hogy átmenjek egy vizsgán, akkor annak eredménye, hogy legalább 2-es lesz a jegyem a tárgyból. Ennek a siker kritériuma, hogy minden nap elolvasok 10 oldalt a jegyzetből. Bukás indikátora pedig az, hogy a vizsga előtt két nappal is hajnalban érek haza a buliból, és fogalmam sincs, hogy egyáltalán miből kéne tanulni. A bukás indikátorok tehát early warningok, amik figyelmeztetnek, hogy nem a szándék felé haladunk. A siker indikátorok segítenek nekünk, hogy tudjuk, mikor járunk jó úton. 

A gyakorlat elején megkértem azt, aki a megrendelőnk oldaláról összehívta a retrót, hogy mesélje el, milyen szándékkal hívta össze az embereket: Legyen jó az együttműködés a két fél között. Eztuán 10 percben mindenki vitatkozhatott, kérdezhetett, és beszélgettünk róla, hogy meglegyen a közös megértés. Ezt bontottuk le konkrét eredményekre, amiben megnyilvánul, hogy az adott szándék felé halad az együttműködés (pl. őszinte kommunikáció, olajozott működés, büszkeség a közös termékre). Volt kb. 10 perce mindenkinek, hogy magában átgondolja, hogy szerinte mi a legfontosabb eredmény. Ezután körbementünk, és én felírtam az eredményeket a táblára. Ezen a ponton fontos volt, hogy tömören és kifejezően fogalmazzuk meg őket, és minden résztvevő megértse a másikét.

Ezt követően dotvotingoltuk az eredményeket, és a három legnépszerűbbet kisebb csapatokra bontva dolgozták ki az emberek.

A csoportmunka szabályai:

  • minden témának van egy témafelelőse;
  • a témafelelős fixen marad a témánál, amit ő kapott;
  • a többiek szabadon mászkálhatnak a témák között (openspace jelleggel).

A csoportmunkában az eredményeket konkrét, mérhető siker, illetve bukás indikátorokra bontottuk le. Megkértem őket, hogy gyűjtsenek a bukás indikátorok mellé embereket, akikhez lehet fordulni, ha bekövetkezni látszanak.

A végén a témafelelősök prezentálták, hogy mire jutottak, és közösen megegyeztek a többiekkel, hogy milyen akcióterveket fognak végrehajtani.

Konkrét példa:

Szándék: Legyen jó az együttműködés a két fél között

Eredmény: Olajozott működés

Siker indikátor: közösen megállapított, a csapatok által betartott definition of done; a product backlog 2 sprintre elő van készítve

Bukás indikátorok: planningen túl sok a nyitott kérdés; sok a panasz a termékrenem tiszták a felelősségi körök

Ezekhez társított action pontok:

@XY a következő két hétben összehív egy meetinget, ahol tisztázzuk, kinek mi a feladata, és elvárása a többiekkel szemben

@YX elővszei a DoD-t, és tisztázzuk, minek kellene benne szerepelnie

stb.

A workshopnak lényegi pontja az akciópontok alkotása, hogy igazi akciótervek szülessenek, amiknek van felelőse, határideje, és konkrétan mérhető. Triviálisnak tűnik, de érdemes kihagsúlyozni, hogy megvalósíthatónak kell lenniük. (Utólag mesélte el nekem négyszemközt az egyik résztvevő, hogy valamelyik akciópont belátható időn belül kivitelezhetetlen. Nem álmokat szövögetünk, hanem javítani akarunk valamin kőkemény munkával.) Hiba továbbá, ha ezerszámra születnek a kiváló akciók. Inkább legyen kevésebb, és priorizáljuk őket.

Tanulságok:

  • A legfontosabb, hogy egyetlen alkalomtól nem fog igazi változás történni. Ahogy már írtam, az akciópontokat, a megállapodásokat és a fájdalmakat következetesen és rendszeresen elő kell venni. Számon kell kérni, mérni kell a megvalósulásukat, beszélni kell a következményekről, és új terveket kell csinálni. Az a tapasztalatom, hogy az ilyen alkalmakon valamennyi résztvevő igazán lelkes tud lenni, ám az ajtón kilépve, a másnap reggeli meetingen már visszahelyezkednek az addig megszokott mintákba, és nem sok minden változik. Ezért nem győzöm hangsúlyozni, hogy fegyelmezettnek és következetesnek kell lenni, ha változást szeretnénk.
  • A csoportmunkánál jól ki kell hangsúlyozni, hogy csináljanak akcióterveket/gyűjtsenek action pointokat, mert csak így lesz változás.
  • Túl sokan voltak, így nem volt elég a két és fél óra. 13 emberrel is tök jól meg lehetett volna csinálni, de legalább 3 és fél óra kellett volna hozzá.
  • A végén, a prezentálásnál vágtam az időt, de nem ott kellett volna, és így nem volt konkrét szavazás, hogy milyen action-öket hajtsunk végre, csak vétózni lehetett a témafelelős javaslatát.
  • A végén megkérdeztem, hogy hogy érezték magukat, és kaptam visszajelzést, ami nekik is és nekem is tök jó volt.
  • A meeting elején az asztal közepére tettem egy kosarat, és az elsőként érkezőket megkértem, hogy dobják be a telefonjukat, és az utánuk érkezők már maguktól belepakolták a sajátjukat! Nagyon jó volt, a retró nagy része interruptmentes volt.
  • A gyakorlat elmagyarázásához több és jobb példát kellett volna vinni, nem mindenki értette meg azonnal. Amivel pedig ment az idő.
  • Jó volt, hogy vittem bluetacket, mert nem volt mágnesezhető a whiteboradjuk. (smile)
  • Ha sok a résztvevő, jó, ha van még egy moderátor, aki tud segíteni nekik a csoportmunkában, hogy hogyan tudnak jó akcióterveket megfogalmazni.

A haladóknak itt az esemény agendája:

  • megérkezés, cél, agenda elmondása - 10 perc
  • előző retró actionjeit átbeszélni - 15 perc
  • gyakorlat elmondása, szándék megköpködése - 15 perc
  • eredmények kigondolása + elmondása + dotvoting - 25 perc
  • csoportmunka szabályainak elmondása + csoportmunka - 25 perc
  • prezentálás + szavazás - 3x10perc
  • visszajelzés - 2 perc

 

Gratulálok! Ha idáig eljutottál, és úgy gondolod, sikerült megízlelni az összejátszás fontosságát, akkor már rákacsintottál az agilitás rögös útjára. A valóságban módfelett nehéz a jó együttműködés fenntartása, de főleg a hozzá szükséges szemlélet kialakítása. Viszont nem együttműködni sem sokkal könnyebb, csak talán kevesebbet kell érte tenni.

Ha tetszett, iratkozz fel a blogomra, vagy kapcsolódjunk linkedinen.

A bejegyzés trackback címe:

https://scrumster.blog.hu/api/trackback/id/tr414852636

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

rmgm 2019.05.24. 23:07:35

"@YX elővszei a DoD-t, és tisztázzuk, minek kellene benne szerepelnie, ezután SM/PO ismerteti a csapattal"

Ismerteti?? A csapat nem vesz részt a retrón és nem ő határozza meg a DoD-t? Minden retróról kihagyjátok a csapatot, vagy csak az EGYÜTTműködést érintőről? Lehet, hogy máshol van a probléma, mint ahol keresitek. :)

nagyeszteranna · https://www.linkedin.com/in/annaeszternagy/ 2019.05.25. 00:07:18

@rmgm: Király, hogy ezt észrevetted! Abszolút igazad van, nem túl jól van kifejezve. Aggodalomra semmi ok, voltak a retrón fejlesztők, utána néhányan a DoD review-n is részt vettek. Három csapat dolgozott a terméken, így nem minden csapattag vett részt, velük pedig ismertetni kellett. És persze volt beleszólásuk a tartalmába.
süti beállítások módosítása