Ez a cikk egy sorozat negyedik része. Ha a többit is el szeretnéd olvasni, itt megteheted:
➔ Sok nagyvállalat helyezi manapság az agilis transzformációt középpontba, és mindenhol az a kérdés vetődik fel, hogy hogyan lehetséges nagy léptékben is megvalósítani a transzformációt, hogyan lehet a nagyvállalatok működését teljes mértékben agilissé tenni. Az előző cikkben azt néztük meg, hogy mindez bizony egyetlen nagy lépésben nem hajtható végre, minthogy egy emberi közösség komplex adaptív rendszert alkot, így azt nem lehet egy előre meghatározott struktúrába beleerőszakolni, és egy újfajta kultúrát ráerőltetni. A változás kulcsa az, hogy meghatározzuk a kívánt irányt, és apró lépésekben valósítjuk meg a változásokat. Az elért hatást értelmezzük, közösen kielemezzük, és az alapján határozzuk meg a következő lépést. Ennek szisztematikus alkalmazása révén lehetőség kínálkozik a meglévő rendszer megváltoztatására.
Az, hogy lehet-e az agilis működés előnyeit nagy léptékben érzékelni, lényegében attól függ, hogy a szervezet kicsiben is képes-e agilisan működni. A struktúrák csak akkor érnek valamit, ha az agilitás „kicsiben” is működik. Érdemes megvizsgálni, hogy milyen problémák jelentkezhetnek mikroszinten, tehát a „valóság talaján”, ahol valódi emberek és csapatok dolgoznak.
1. Van-e vezető egy önszerveződő csapaton belül?
➔ Sokan azt gondolják, hogy egy önszerveződő csapatban nincs vezető, mert mindenki egyenrangú csapattag (egyenrangú, és nem egyforma). Fontos azonban tisztázni, hogy mit is értünk vezetés alatt. Sokaknak a vezetésről az egyszemélyi irányítás jut eszébe; ez a típusú vezetés valóban nem értelmezhető a (valódi) önszerveződő csapatok esetén.
Általánosabb értelemben a vezetés azt jelenti, hogy valaki képes az elvégzendő feladatokat úgy megszervezni, és a munkatársait úgy motiválni e feladatok elvégzésére, hogy az mindenkiben a határozott iránymutatás érzetét keltse. Azaz, ha hisz valaki valamiben, és azt képes megfelelően is kommunikálni, akkor a hite, meggyőződése átragadhat másokra, akik ezután követni fogják őt. (Angolul a leader és manager két külön szó, míg magyarban a vezető szó mindkét szerepre használatos.)
Így bárki vezetővé válhat a csapatban, sőt valójában elkerülhetetlen, hogy egy csapaton belül egymás vezetőivé váljanak a csapattagok. Ennek az az oka, hogy ahhoz, hogy a csapattagok elismerést kaphassanak a társaiktól (mivel ők azok, akik leginkább meg tudják ítélni a másik hozzájárulását a munkához), mindenkinek lehetőséget is kell biztosítani arra, hogy kifejezhesse saját magát a munkában, és ne csak a számára kijelölt feladatokat végezze el gépiesen.
A csapattagok vezetői szerepvállalásra való hajlandóságát ezért tudatosan fejleszteni szükséges, hogy képesek legyenek, merjék az ötleteiket előadni, „eladni” a többieknek. Ahhoz, hogy valamit „eladhassunk” a többieknek vezetőként (és egyben csapattagként is), tisztában kell lennünk azzal, hogy számunkra mi a fontos. Ugyanis konfliktushelyzet esetén tudnunk kell, hogy az adott ügyben miért és milyen mértékben kívánjuk felvállalni az adott konfliktust.
Pontosan mi a célunk az egyet nem értésünk kifejezésével? Mennyire fontos nekünk az adott ügy/feladat? Miért láthatja a másik másképpen a helyzetet? Mit tanulhatnánk tőle? Mit tanulhatnánk egymástól? Lehet, hogy igazából mindkettőnknek igaza van? Mi akadályoz meg abban, hogy elengedjük a dolgot? Mi az, ami az adott szituációban számunkra feltétlenül fontos, és miért? Ezek olyan kérdések, amelyek megválaszolásához megfelelő önismeret, nyitottság és bátorság is szükséges.
A vezetői szerep felvállalásához az is kell, hogy a csapattagok képesek/hajlandóak/akarjanak is vezetettek lenni. Ehhez el kell fogadnunk a másikat, aki vezetni próbál minket. Fel kell tudnunk egymást emelni, biztatni, hagyni, hogy a másik is érvényesüljön, és megvalósíthassa a segítségünkkel azt, amit elképzelt. A saját erősségeink kiaknázásával segítsük a másik elképzeléseinek megvalósítását, és ha így teszünk, a társunk is ugyanígy fog tenni fordított helyzetben. A vezetés-vezetettség így egy dinamikusan változó viszonyt eredményezhet két fél között, ami a teljes csapatra jellemzővé válhat mintegy behálózva azt.
2. Mi a helyzet a vezető fejlesztő (szakmai vezető) személyével a csapatban?
➔ Gyakori, hogy a csapaton belül van egy kinevezett szakmai vezető (vezető fejlesztő, tech lead), akár egy agilisnak kikiáltott szervezetben is. Valóban előfordulhatnak olyan helyzetek, amikor szükség lehet arra, hogy valaki betöltse a megfelelő autoritással felruházott szakmai vezető szerepét.
Például adott egy rövid határidőjű projekt (pár hónap) és egy új csapat, amiben a csapattagok szakmai tapasztalata tekintetében nagy eltérések mutatkoznak (pl. juniorok is vannak a csapatban), esetleg a csapat tagjai nem is ismerik még egymást. Ilyenkor nincs idő arra, hogy a csapat közös normákban egyezzen meg, és csapatépítéssel erősítsék meg a bizalmat.
Hosszútávon ilyenkor az jelenthet megoldást, ha állandó összetételű csapatokkal dolgozunk a stabilitás megteremtése és a csapattagok közötti különbségek kiegyenlítése érdekében.
A kinevezett vezető mint autoritás nincs összhangban az önszerveződő csapatok koncepciójával, ezért fontos tudnunk, hogy ha van is kinevezett szakmai vezető, az ő elsődleges céljának annak kell lennie, hogy a tudását és autoritását mihamarabb fokozatosan átadja a csapattagoknak, ezáltal csökkentve az ismeretbeli különbséget, és kiegyenlítve a hatalmi viszonyokat a tagok között, hogy a valódi csapatként való (együtt)működés minél inkább megvalósulhasson a gyakorlatban. Ehhez a szakmai vezetőnek megfelelő emberi kvalitásokkal kell rendelkeznie, és képesnek kell lennie a mentori szerep ellátására. Ehhez pedig olyan attitűd szükségeltetik, amely a másik személy egyenrangúvá tételét tartja fontosnak a saját státuszának erősítése helyett. Nem szabad domináns szerepet felvennie, hanem meg kell találnia azt az egyensúlyt, hogy teret engedjen a kevésbé tapasztaltaknak, azonban közbe is tudjon lépni, ha szakmai szempontból nem a megfelelő irányba haladnak a dolgok. Ez igencsak ingoványos terület, hiszen annak megítéléséhez, hogy „valami szakmailag nem megfelelő”, a szakmai vezetőnek az autoritásával kell élnie, tehát ha ehhez az eszközhöz nyúl, akkor tudnia kell, hogy ebben az esetben tekintélyt és hatalmat gyakorol, ami a csapatként való együttműködés ellen hat abban a pillanatban. Sok esetben meg kell tudnia győznie a többieket, miközben tanítja is őket. Ha megfelelő alázattal és nyitottsággal fordul a kevésbé tapasztalt csapattársai felé, akkor biztosan el fogják fogadni, és tisztelni fogják a pozíciójától függetlenül. De egy agilis csapatban amúgy is ez az „alapfelállás”, bárkiről is legyen szó.
Vigyázzunk, mert nagyon könnyen eshetünk abba a hibába, hogy elkezdünk igazolást keresni arra, hogy a szakmai vezetői szerepünkre mindenképpen szükség van. Főleg akkor, ha úgy érezzük, nem tudjuk meggyőzni a többieket, és az irányítás kezd kicsúszni a kezeink közül. Vagy például akkor, ha időnyomás miatt úgy gondoljuk, hogy nincs lehetőség a kiegyensúlyozott döntéshozatalra, hanem azonnal kell döntenünk. Nagyon nehéz, de minden helyzetben arra kell törekednünk, hogy hatékonyan meg tudjuk oldani a helyzetet, a tekintélyünk ráhatása nélkül. Vannak olyanok, akiknek ez személyiségünknél fogva sokkal könnyebben megy, valakinek ez sokkal nehezebb.
A junior munkatársak gyakran azzal a hozzáállással válnak csapattaggá, hogy csak mondják meg nekik, mit kell csinálni, mert ők még nem tudják, ami bizony nagyon kényelmes attitűd a részükről. De nem csak részükről, hanem a szakmai vezető részéről is, hiszen van valaki, akinek meg lehet mondani, hogy mit hogyan csináljon. Bármennyire is gyümölcsözőnek tűnik elsőre az ilyen kapcsolat, egy idő után biztosan visszaüt, hiszen a junior kolléga nem fog fejlődni, és állandóan a szakmai vezetőre lesz utalva.
3. Hol a helye az architectnek az agilis működésben?
➔ Az architectnek nem szabad a csapat helyett döntenie, hiszen azzal sérülne a csapat autonómiája. Lehetnek azonban olyan szempontok, amelyeket az architect képvisel a szervezetben, és ilyenkor ezeket a szempontokat a csapatnak is figyelembe kell vennie. Ilyenkor is a csapat és az architect között win-win helyzetre kell törekedni.
Egy architectnek azt is érdemes megfontolnia, hogy a tanácsai, iránymutatásai mennyire adekvátak, amennyiben ő maga nem ismeri a kódot. A 11. agilis elv ki is mondja, hogy a legjobb architektúrák önszerveződő csapatok kezei közül kerülnek ki. Nem véletlenül, ugyanis a kollektív intelligencia és a gyakorlatban történő tanulás előrébb való, mint az upfront tervezés, amit „csak” egy személy végez.
Előfordulhat, hogy valaki olyan tudás vagy szakmai tapasztalat birtokában van, hogy szakértőnek számít egy adott témában. Ilyenkor arra kell törekednie, hogy ezt a tudását átadja, és rá a későbbiekben ne is legyen szükség – még ha ez a valóságban nem is valósul meg mindig maradéktalanul.
4. Akkor az agilis csapatok demokratikusan működnek?
➔ A csapattagok egyenrangúak, így konszenzusos döntéseket hoznak meg. Nyilván nem arról van szó, hogy minden kódsorért engedélyt kell kérni valaki mástól, de lehetnek olyan lényegi döntések, amelyek a teljes csapatot érintik, így ezeket mindenképp együttesen célszerű megbeszélni. Például, a csapatnormákat közösen kell megbeszélniük (pl. mostantól code review-zunk).
A konszenzusos döntés egyik hátulütője, hogy nagyon lassú döntéshozatali folyamatot eredményezhet. Az angol „ask for forgiveness, not permission” mondás remekül kifejezi, hogy a szakmai bizalmat élvező munkatársak ne akarjanak állandóan engedélyt kérni, ha valamit szeretnének csinálni, hanem csinálják, amit szeretnének, és ha valakivel esetleg összetűzésbe kerülnének, akkor elegendő utólag bocsánatot kérniük.
Ennek gyakorlati megvalósításában segíthet az advice process (tanácsadási folyamat), aminek az a lényege, hogy bárki hozhat döntést a szervezetben, azonban előzetesen meg kell arról kérdezni a terület szakértőjét és azokat az embereket, akikre hatással lesz az adott döntés.
A szakértő nem mondhatja meg, mit csináljunk (hiszen mi vagyunk a döntéshozók), ellenben nekünk kötelező figyelembe venni az ő véleményét, és természetesen azokét is, akikre a döntésünk majd hatással lesz.
5. Egy scrumcsapat egyben önszerveződő is?
➔ A Scrum Guide világosan fogalmaz ezzel kapcsolatban: a fejlesztői csapat önszerveződő. Ha nem önszerveződő a csapat, akkor nem hívhatjuk azt a működési formát scrumnak. A valóságban viszont gyakran scrumnak neveznek olyan csapatot is, amely lényegében csak az előírt „ceremóniákat” tartja meg (vagy azokhoz hasonlóakat), és a best practice-eket alkalmazza. Valójában a „soft” előírásokkal sem nagyon foglalkoznak, és azok így sokszor szubjektív megítélés alá esnek (doing agile without being agile).
6. Mi az önszerveződés legnagyobb gátja?
➔ Nagyon sok oka lehet annak, ha az önszerveződés nem működik. Nincs garancia arra, hogy egy csapat képes jól együttműködni. Ennek okai kereshetők a csapaton belül és kívül is. A leggyakoribb okok a következők:
- Nem tartják tiszteletben a csapat autonómiáját, esetleg a felelősségek nincsenek világosan meghatározva a csapat vagy a csapattagok tekintetében.
- A vezető/architect/projektmenedzser/product owner/business analyst/rendszerszervező akarja megmondani, hogyan dolgozzon a csapat, esetleg még a sprint közben is beleszólnak a csapat működésébe.
- Nincsenek egyértelműen meghatározva a feladatok/célok a csapat számára.
- Nincs bizalom a csapaton belül.
- Nincs bizalom a csapat irányába.
- A csapattagok egyéni céljai, motivációi nincsen a csapat törekvéseivel összhangban.
- A csapattagok nem rendelkeznek megfelelő önismerettel, és/vagy nem képesek képviselni a saját érdekeiket.
- A csapaton belüli konfliktusok nem kerülnek feloldásra, a csapatdinamika nincs figyelembe véve (így a tagok idővel magukba zárkóznak).
Ezen okok erősíthetik is egymást, illetve együttesen is előfordulhatnak.
7. Mit tehetünk, ha az egyik csapattag túl domináns?
➔ Egyenrangú félként megemlíthetjük a másiknak, hogy nem tudjuk kellően kifejteni és képviselni az álláspontunkat (asszertív kommunikáció). Egy jó scrummasternek viszont észlelnie kell a probléma jeleit, és kezelnie is kell ezt általában oly módon, hogy külön elbeszélget az illetővel. Nem minden esetben lehetséges azonban elérni, hogy az adott személy tartósan változtasson a viselkedésén. Amennyiben az illető pl. szakmai vezető a csapaton belül, és magas politikai motivációval bír, akkor mindent ő szeretne kontrollálni. Ez egy olyan vágy (értékpszichológia), amely tudatalatt működik.
- Egy megoldás lehet, ha sikerül olyan kontrollmechanizmust találni, ami a csapat munkáját is segíti és azzal a csapat is egyetért.
- Másik megoldás lehet, hogy az ilyen személyiségnek is megtaláljuk a megfelelő szerepet, persze nem feltétlenül a csapaton belül.
8. Hogyan tudunk csapatként dolgozni, ha mindenkinek más a szakterülete?
➔ Gyakran előfordul, hogy a csapaton belül leosztásra kerülnek az egymással átfedésben nem lévő felelősségek (pl. enyém a frontend, tied a backend, vagy: én fejlesztek, te tesztelsz). Egy ilyen szigorú felosztás egyáltalán nem tesz jót a csapatmunkának, mivel elszigeteli egymástól a tagokat, és a kapcsolódási pontok esetében (integráció) nem lesz felelős.
Sokkal szerencsésebb megoldás kapcsolódási pontokat találni (pl. alapvetően frontendes vagyok, de értek egy kicsit a backendhez is, így apróbb dolgokat én is ki tudok javítani; vagy: a fejlesztő is ír teszteseteket, nem csak a tesztelő, esetleg közösen találják ki őket stb.).
A strong/weak code ownership esetében is arra célszerű törekedni már középtávon is, hogy kiegyenlítődjön a csapattagok között meglévő esetleges tudásbeli különbség.
Projektszerű működés (pár hónapos átfutási idő) esetén pedig az segíthet, ha a csapat stabil marad, és nem kerül minden projekthez új csapat kialakításra.
9. Meddig terjed a PO felelősségi köre a fejlesztői csapattal szemben?
„The Product Owner is the sole person responsible for managing the Product Backlog.”
„No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;”
Ez a két pont azt jelenti, hogy a PO a felelős a productbacklogért, a fejlesztői csapat pedig a megvalósításért. A PO nem mondhatja meg, hogyan valósítsa meg a csapat a productbacklog elemeit.
10. Több csapat esetén hol kerülnek kijelölésre a csapatok közötti határvonalak?
➔ Ez egy elméleti kérdés, mivel a valóságban a csapatok organikusan fejlődnek ki (ld. komplex adaptív rendszerek), egy önszerveződő szervezet pedig képes döntést hozni ez ügyben is.
11. Nem szeretem a scrumot, mert mindennap számon kérnek, hogy hogyan állok a feladatommal.
➔ A napi standup gyakran számonkéréssé „fajul” olyan környezetben, ahol kontrollt akarnak gyakorolni a sprint végrehajtása közben is. Ez ellentmond az önszerveződési elveknek, amik a csapat számára autonómiát írnak elő. A napi standup – a sok félreértés ellenére – nem egy státuszmeeting, hanem egy „tervezőeszköz”, ami segít a csapatnak abban, hogy koordinálja a saját munkáját, áttekintse, hol áll a sprint közben, és megállapítsa, teljesíteni tudja-e a sprint célját. Amennyiben nem, meg kell tennie a szükséges intézkedéseket az adott cél teljesítése érdekében.
Konklúzió
Az önszerveződő (vagy agilis) csapatok koncepciója nagyon fontos az agilis működés megvalósítása során. A gyakorlatban mindig komoly nehézségek adódnak ezen ideálisnak tekintett működési forma megvalósítása közben. Azonban ha tisztában vagyunk azzal, és tudatosítjuk magunkban és környezetünkben, hogy miért is szeretnénk önszerveződő csapatokat létrehozni, vagy azokban dolgozni, akkor hamar kiderül, hogy az általunk fontosnak tartott értékek (pl. egymás iránti érzékenység és nyitottság, együttműködés stb.) érvényesülnek-e, és ha igen, milyen mértékben. Szükség esetén a csapattagok vagy az arra felhatalmazott személy (pl. scrummaster vagy vezető) tudatosíthatja a kialakult helyzetet, vagy akár változtathat is azon. Valójában már a tudatosítással is minden esetben változtatunk a helyzeten.
Az önszerveződő csapatok kialakítása a konkrét struktúrák megteremtésén túl az emberi kapcsolatok „menedzselésének” művészetének is tekinthető. Akkor jó a csapat, ha kiegyensúlyozottan, azaz fenntartható módon képes működni az elvárt hatékonyság mellett. Az emberi konfliktusok felvállalásához és megoldásához motivált és kellőképpen érzékeny egyénekre van szükség.
Az önszerveződő csapatok a jövő szervezeteinek építőkockái.
Ez a cikk egy sorozat negyedik része. Ha a többit is el szeretnéd olvasni, itt megteheted:
