01
Kiinduló helyzet
Belső fejlesztési és üzleti szereplőkből álló csapat, amely korábban alapvetően együttműködően, ritka és kezelhető szakmai súrlódásokkal dolgozott.
Esettanulmány · Human behavior
Amikor az együttműködés sérül
Egy fejlesztési csapatban nem az eszközök vagy a módszertan hiánya okozta a legnagyobb delivery-kockázatot, hanem az, ahogyan az információ, a döntés és a szakmai visszajelzés egyre inkább egyetlen szereplőn keresztül kezdett áramlani.
Röviden
A delivery néha nem azért romlik, mert nincs folyamat. Hanem mert sérül a bizalom.
A csapat korábban alapvetően működött: voltak ritka, kezelhető szakmai súrlódások, de ezeket többnyire meg lehetett beszélni. A törés akkor jelent meg, amikor az információ és a döntés egyre inkább egyetlen ember köré szerveződött, a szakmai viták személyesebbé váltak, és a csapat elveszítette a közös tanulás természetes ritmusát.
02
Valódi probléma
Az információ és a döntés egyre inkább egyetlen szereplőnél torlódott fel, miközben a szakmai visszajelzés nem épült be a működésbe.
03
Javasolt megoldás
Semleges facilitáció, szerep- és döntési jogkör tisztázás, user story review, meetingkeretek és transzparens információáramlás.
Kontextus
Egy alapvetően működő csapatba érkezett egy új, hierarchikus vezetői minta.
Az eset egy szabályozott, pénzügyi környezetben működő fejlesztési csapatról szól. A fejlesztői és üzleti oldal több szerepkörben dolgozott együtt: az igények, a fejlesztés, a tesztelés és az átadás összehangolása közös figyelmet igényelt.
Pár év közös munka után új munkatárs érkezett, aki bankszektorban dolgozott azelőtt, de nem rendelkezett szoftverfejlesztési, Product Owner vagy Business Analyst háttérrel. A betanulási időszak alatt is érzékelhető volt, hogy később vezetői szerepet kap, miközben még nem ismerte mélyen az agilis működést, a Jira / Confluence használatát és a csapat korábbi informális megállapodásait.
A probléma nem az volt, hogy új ember érkezett. Hanem az, hogy a tanulási időszak helyett nagyon hamar olyan hierarchikus működés alakult ki, amelyben a tudás, a kommunikáció és a döntés egyre inkább egyetlen embernél torlódott fel.
Diagnózis
Három területen látszott igazán a törés: információ, meetingek, backlog.
Az eset nem egyetlen konfliktusról szólt, hanem ismétlődő mintázatról. A szakmai egyeztetések egyre kevésbé közös problémamegoldásként működtek, és egyre több energia ment el arra, hogy a csapat utólag tisztázza, ki mit tud, ki mit döntött és mit kellett volna valójában megépíteni.
Információáramlás
Korábban a releváns szereplők jellemzően ráláttak az egyeztetésekre. Az új működésben ez fokozatosan megváltozott: egyre több kérdés, válasz és döntés egyetlen embernél állt meg, és a tudásmegosztás helyett információs szűkület alakult ki.
Elromlott működés
- az egyeztetések és válaszok egyre gyakrabban egyetlen szereplőn keresztül futottak;
- a levelezésekből és háttéregyeztetésekből sokszor kimaradtak azok, akiknek dolgozniuk kellett volna az információval;
- a tudásmegosztás helyett az információ egy embernél kezdett felhalmozódni;
- a működés azt az érzetet keltette, hogy a folyamatok csak rajta keresztül mozdulhatnak tovább.
Ez miért baj?
- az információ egyre gyakrabban nem jutott vissza a teljes üzleti csapathoz;
- a döntések és válaszok háttere nem volt mindenki számára látható;
- a csapat tagjai más-más információból dolgoztak;
- a transzparencia hiánya bizalmi problémává alakult.
Javaslat
- rögzíteni kell, kiket kell bevonni az üzleti és fejlesztési egyeztetésekbe;
- a döntéseket közös, visszakereshető felületen kell dokumentálni;
- a csapat ne személyes postafiókokból, hanem közös információs alapból dolgozzon;
- egyértelműsíteni kell, mikor válaszolhat valaki egyedül, és mikor kell csapatszintű válasz.
Meetingek és csapatdinamika
A standupok, groomingok és retrok korábban többnyire működtek: ha volt is feszültség, ritka volt, és általában meg lehetett beszélni. Később a szakmai egyeztetések gyakrabban fordultak személyes konfliktusba, és a meetingek elveszítették a közös problémamegoldó jellegüket.
Elromlott működés
- a szakmai egyeztetések egyre gyakrabban személyes hangvételű vitába fordultak;
- a meetingek célja sokszor nem döntés vagy tisztázás lett, hanem pozíciók védése;
- a visszajelzés könnyen lojalitási kérdésnek tűnt, nem működési javításnak;
- a csapat kevésbé merte nyíltan jelezni, ha egy döntés, story vagy működés nem volt megfelelő.
Ez miért baj?
- a meetingek egy része nem döntéshez, hanem feszültséghez vezetett;
- a visszajelzés nem működési kérdésként, hanem lojalitási problémaként jelent meg;
- a csapat energiája a védekezésre és pozícióharcra ment el;
- a pszichológiai biztonság csökkent, így kevesebb valódi probléma került időben felszínre.
Javaslat
- semleges facilitátorral újra kell keretezni a standup, grooming és retro célját;
- meeting agreement szükséges: hogyan vitázunk, hogyan parkolunk témát, hogyan zárunk döntést;
- a konfliktust nem személyekhez, hanem működési mintákhoz kell kötni;
- biztonságos visszajelzési csatornát kell kialakítani az üzleti és fejlesztői oldal között.
User story-k és backlogminőség
A szerepkörbeli bizonytalanság és a visszajelzés elutasítása közvetlenül megjelent a backlogban. A user story-k gyakran hiányosak vagy pontatlanok voltak, miközben a szakmai javítás nem tanulási folyamatként, hanem személyes kritikaként jelent meg.
Elromlott működés
- a story-k előkészítése egyre inkább egyetlen szereplő kontrollja alá került;
- a PO / BA / tesztelői tapasztalat nem tudott természetesen beépülni a feladatokba;
- a groomingon adott szakmai visszajelzések gyakran ellenállást váltottak ki;
- a backlog minősége romlott, mert a közös pontosítás helyett védekezés és újrajavítás alakult ki.
Ez miért baj?
- hiányos vagy pontatlan story-k miatt a fejlesztés többször visszafordult javításra;
- minden sprintben kapacitás ment el korábbi félreértések korrigálására;
- a szakmai visszajelzés személyes kritikának tűnt, ezért a story-minőség lassan javult;
- a csapat morálját rontotta, hogy új érték szállítása helyett újra és újra javításokkal kellett foglalkozni.
Javaslat
- új PO esetén kötelező story review és onboarding szükséges IT / agile környezetben;
- közös user story standardot, acceptance criteria mintát és DoR / DoD alapot kell használni;
- a grooming célját tanulási és pontosítási alkalomként kell visszaállítani;
- a backlogminőséget nem személyes teljesítményként, hanem delivery-kockázatként kell kezelni.
Hatás
A probléma végül nem csak hangulatban, hanem deliveryben is megjelent.
A csapatműködés romlása nem maradt „soft” probléma. A story-k minősége, az információáramlás és a meetingek hatékonysága közvetlenül hatott arra, hogy mennyit tudott a csapat új fejlesztésre fordítani.
1
Információs szűkület
Túl sok kérdés, válasz és döntés torlódott fel egyetlen szereplőnél.
↓
Story-minőség
A hiányos vagy pontatlan user story-k miatt több utólagos javításra volt szükség.
↑
Meetingfeszültség
A szakmai egyeztetések gyakran személyesebb, kevésbé hatékony irányba mentek el.
↓
Morál és tempó
A folyamatos javítás és tisztázás csökkentette az új fejlesztésekre fordítható energiát.
Az ilyen hatások sokszor nem egyetlen metrikában jelennek meg. A jelek inkább együtt olvashatók: több újranyitott kérdés, több konfliktusos meeting, több félreértett story, lassabb döntés és romló csapatbizalom.
Beavatkozás
Ilyen helyzetben nem elég „megbeszélni”. Külső, semleges keret kellhet.
A helyzetet belülről többféleképpen próbálták kezelni: közvetlen beszélgetéssel, visszajelzéssel és vezetői jelzéssel is. Mivel azonban a probléma ismétlődő működési mintává vált, egy külső facilitátor nagyobb eséllyel tudta volna láthatóvá tenni a mintázatokat.
Semleges facilitáció
Agile coach, delivery coach vagy külső szakember bevonása, akit egyik oldal sem saját emberének érez, és aki nem személyeket, hanem működési mintákat vizsgál.
Szerepek és döntési jogkörök
Ki dönt scope-ról, ki ír story-t, ki validál üzleti igényt, ki adhat szakmai visszajelzést, és hol kell közös döntés?
PO / BA működési keret
Story review, DoR / DoD, acceptance criteria standard és közös grooming-szabályok, hogy a feedback ne személyes kritika, hanem minőségbiztosítás legyen.
Tanulság
A szoftverfejlesztés nem egyetlen ember nézőpontja köré szerveződik.
Vannak környezetek, ahol a gyors, hierarchikus döntés indokolt. Egy szoftverfejlesztési csapat azonban nem ilyen: a minőség abból is jön, hogy a fejlesztő, a tesztelő, a Business Analyst, a Product Owner és az üzleti terület más-más oldalról látja ugyanazt a problémát.
Az agilis működés nem attól sérül, hogy van vezető. Attól sérül, ha a vezető nem facilitálja a szakmai párbeszédet, hanem kisajátítja az információt és a döntést.
Ha a csapat nem mer kérdezni, vitatkozni vagy szakmai visszajelzést adni, akkor a delivery előbb-utóbb nem csak lassabb lesz, hanem pontatlanabb is.