Önszerveződő csapatok (2. rész): Hogyan működnek az önszerveződő csapatok?

Szerző: | 2019. 06. 03. | Agilis szoftverfejlesztés

Olvasási idő:

➔ A hagyományos hierarchikus működés ma az uralkodó menedzsmentszemlélet. A hétköznapokban az emberek túlnyomó többsége is ezt tekinti az egyedüli működőképes modellnek. Olyannyira elfogadják, hogy eszükbe se jut, hogy ez valójában másképpen is lehetne. Pedig az emberiség történetében csak az utóbbi pár száz évben dominált ez a típusú irányítási modell, előtte kisebb csoportok, törzsek szintjén hozták meg a döntéseket.

Pedig ma a nemzetközi színtéren is tudunk teljes mértékben önszerveződő alapon működő vállalatokról, amiknek több ezer alkalmazottjuk van. Mindenféle iparág képviselteti itt magát, a for-profit és nonprofit szektor is, így nem kérdés, hogy a modell működőképes. Ez persze nem jelenti azt, hogy minden szervezetnek teljes mértékben önszerveződő alapon kell működnie, ez nem is tűnik középtávon sem reális célkitűzésnek. Ha viszont megértjük az önszerveződés előnyeit és működésének elvét, akkor bizonyos helyzetekben választhatjuk ezt a nehezebbnek tűnő, de sokkal inspirálóbb, emberibb és jóval nagyobb eredménnyel kecsegtető utat.

Az agilis szoftverfejlesztés e modell mellett tette le a voksát a szoftverfejlesztő csapatokra vonatkozóan.

Mitől működnek az önszerveződő csapatok?

➔ A hagyományos hierarchikus modell a „command and control” elvet alkalmazza, és a tekintélyt (más néven autoritást vagy főnök-beosztotti viszonyt) használja fel az irányítás biztosításához.

Mindannyian tudjuk, hogy a külső motivátorok csak ideig-óráig fejtik ki hatásukat, ráadásul bizonyos esetekben (pl. pénz mint ösztönző) visszavonhatatlanul alá is áshatják a kreativitást és ezzel együtt a belső motivációt, ezért önszerveződő csapatok esetén a külső motivátorok alkalmazása helyett inkább a belső motiváció kiaknázását helyezik előtérbe.

Különféle modellek és kutatások próbálják a jól működő csapatok titkát feltárni.

Pszichológiai biztonság

➔ A Google 2015-ös tanulmánya szerint kevéssé számít az, hogy konkrétan kik a csapat tagjai, és valójában a pszichológiai biztonság az a messze legfontosabb tényező, amely meghatározza egy csapat eredményességét. A pszichológiai biztonság azt jelenti, hogy a csapattagok olyan környezetben dolgozhatnak, ahol kockázatot vállalhatnak anélkül, hogy rosszul éreznék magukat közben, vagyis nem kell félniük attól, hogy ezzel sebezhetővé válnak.

Ezenfelül fontosnak találták még a következő négy szempontot is, azonban a pszichológiai biztonsághoz képest kisebb súllyal esnek latba:

  • Tudnak-e egymásra számítani a csapattagok?
  • Világosak-e a célok, szabályok és végrehajtási tervek a csapatra vonatkozóan?
  • Olyan munkát végeznek-e, amely mindannyiuk számára egyénileg is fontos?
  • Valóban hisznek-e abban, hogy az általuk elvégzett munka számít?
Pozitív pszichológiai eredmények

➔ Megemlíthető továbbá Martin Seligman, a pozitív pszichológia atyjának kutatási eredménye is. Seligman a következő 5 alappillért határozta meg, amik jelentősen hozzájárulnak az emberek jóllétéhez (ezek több esetben összecsengenek a Google fent említett eredményével, de annál bővebb meghatározást adnak):

  • Értelem és célok: Keressünk mindenben értelmet, állítsunk magunk elé célokat, aprókat vagy nagyokat, de mindig reálisakat a mindennapok szürkeségében.
  • Eredmények és sikerek: A sikerek az elégedettség érzésével jutalmaznak meg minket, és ha a céljaink reálisak, akkor sikerre is vihetőek.
  • Elmélyülés és szenvedély (flow-élmény): Végezzünk olyan tevékenységeket, amelyeket igazi odaadással, szenvedéllyel végezhetünk.
  • Pozitív érzelmek: Képesek vagyunk azokra az élményekre, tapasztalatokra helyezni a hangsúlyt, amelyek pozitív hozadékkal járnak.
  • Valódi kapcsolatok: Szenteljünk figyelmet azoknak a kapcsolatainknak, amelyeket a szívünk mélyén fontosnak érzünk.
Osztott felelősség

➔ A hagyományos hierarchikus modellben minden feladat elvégzéséért egyvalaki felelős, így biztosítható a számonkérhetőség és a felelősségre vonás. Az agilis csapatok esetében nincs egyszemélyi felelős, a felelősségi körök a csapaton belül megosztásra kerülnek a tagok között. Például, általában mindenki felel a minőségért, nem csak az, akit erre kineveztek. Természetesen ettől még lehetnek olyan szerepkörök, amelyeket dedikáltan egy-egy ember végez, de ezeket célszerű csak időlegesen alkalmazni (pl. heti rotálásban felel valaki a supportfeladatokért, vagy mindig az végzi a code review-t egy leimplementált sztorinál, aki éppen ráér).

Nehéz lehet elképzelni, hogyan működhet a gyakorlatban egy osztott felelősséggel rendelkező csapat annak, aki még nem dolgozott hasonló környezetben. Valójában a csapattagok közös elkötelezettsége a cél/ügy iránt, a bajtársiasság és az ezekből fakadó „peer pressure”, azaz a pozitív értelemben vett csoportnyomás teszi lehetővé, hogy ne legyen szükség egyszemélyi felelősökre. Ez csak abban az esetben járható út, ha a csapatban is meg tudnak, meg lehet bízni. A vezetőknek is képesnek kell lenniük arra, hogy „elengedjék a gyeplőt”, és teljes egészében átadják a csapatnak a felelősséget a csapattagokat érintő területeken, és az is fontos, hogy a csapat is képes legyen folyamatosan, megfelelő minőségben szállítani a vállalásainak megfelelően.

A megfelelő bizalmi szint fenntartásán folyamatosan dolgozni kell, annak elérése és megtartása kiemelt fontosságú. Ha a cél/ügy mindenki számára fontos, akkor az máris sokkal könnyebbé válik.

A megfelelő bizalmi szinthez általában szükséges a megfelelő transzparencia biztosítása is. Mindenki nyílt lapokkal játszik, és így tudható, hogy ki min dolgozik, milyen feladatokkal végzett. Az átláthatósággal azonban nem szabad visszaélni. Nagyon gyakori például, hogy a SCRUM-ban alkalmazott daily standupokat a csapattagok egyéni számonkérésére használják fel (status report).

Közös normák és értékek

➔ A bizalom megteremtésének egyik feltétele, hogy a csoport tagjai azonos normákat valljanak, azonos értékek mentén gondolkozzanak. Ha egyéni értékekről beszélünk, akkor egy jól működő agilis csapat esetében elengedhetetlen az egymás iránti tisztelet és nyitottság (mindannyian mások vagyunk, és másképpen gondolkozunk), a gyakorlatiasság, a folyamatos tanulásra törekvés (a másik hibáztatása helyett), a fenntarthatóságra törekvés, a felelősség vállalása, másoknak való segítségnyújtás és a kockázatvállalás. A growth mindsetből származtatott agilis mindset a folyamatos tanulást helyezi előtérbe: folyamatosan fejlesztjük magunkat, reflektálunk a múltra, tanulunk egymás hibáiból és egymástól is.

Az értékeket fontos szakmai értelemben is tisztázni a csapatban. Ha én például fontosnak tartom, hogy unitteszteket írjunk a fejlesztendő szoftverhez, akkor meg kell állapodnom a csapat többi tagjával is erről annak érdekében, hogy egyetértés legyen a csapaton belül azzal kapcsolatban, hogy mikor és hogyan írjunk unitteszteket.

Ha megegyeztünk a közös normákban és értékekben, akkor ahhoz tartanunk is kell magunkat. Ha ez nem történik meg, akkor a bizalmi szint jelentősen lecsökken először a csapaton belül, utána pedig a csapat irányába is.

Soft skillek

 Egy önszerveződő csapatban nem várhatjuk el, hogy egy főnök intézze el azokat a dolgokat, amelyeket mi nem tudunk, nem szeretünk vagy nem akarunk megcsinálni. A panaszkodást és mások hibáztatását a proaktivitásnak és az egyéni felelősségvállalásnak kell felváltania. Egyénileg kell fejlődnünk abban a tekintetben, hogy minél eredményesebben tudjunk egy önszerveződő csapatban dolgozni. Rengeteg fejlesztendő skillt lehetne itt megemlíteni, a listának sose lenne vége: kezdeményezőkészség, rugalmasság, vitakészség, konfliktuskezelés, időmenedzsment, stresszmenedzsment, felelősségvállalás, átkeretezési képesség, érzelmi intelligencia stb.

Ez talán soknak tűnhet, de valójában ez egy fejlődési utat kínál fel mindenkinek saját magára tekintettel is, és nem csak szakmai értelemben.

Átfedő hard skillek

➔ Az angol „T-shaped people” kifejezés jól érzékelteti, hogy olyan egyénekre van szükség, akik egyrészt jól értenek a szakmájukhoz (T betű hosszú szára), viszont széles látókörrel, nyitott hozzáállással is rendelkeznek (T betű teteje), ezáltal képesek másokkal a megfelelő kapcsolatteremtésre.

Ha ez nem teljesül, akkor a csapaton belül a tagok nem lesznek képesek, vagy sokkal nehezebben tudják majd megérteni egymást, ami befolyásolja az egymással való kapcsolatukat is. A csapaton belül kisebb klikkek alakulhatnak ki, magányos farkasok dolgozhatnak. Tipikusan előforduló eset szoftverfejlesztő csapatokban például, hogy a backendfejlesztőt nem érdekli a frontend, és fordítva. Ez nem szerencsés hozzáállás, mivel konfliktusokhoz és szuboptimális megoldásokhoz vezethet a csapaton belül, valamint a közös felelősségvállalás elve is sérül, mert mindenki csak a saját területéért akar csak felelősséget vállalni, azzal viszont nem foglalkozik senki, hogy a két területnek hogyan kellene illeszkednie, jól együttműködnie a másikkal. Nem kell egy backendfejlesztőnek szakértőnek lennie a frontendfejlesztés területén, de egy kicsit ismernie szükséges azt (és ez természetesen fordítva is áll), hogy a két terület képviselői meg tudják érteni egymást, egymás problémáit, hogy legyen egy közös alapjuk a későbbi beszélgetésekhez. Annál jobb, minél nagyobb az átfedés, mert így a munka is könnyebben szervezhető meg. Viszont ez egyáltalán nem jelenti azt, hogy mindenkinek mindenhez ugyanúgy kell értenie.

A csapat szintjén a keresztfunkcionalitás fontos szempont, azaz, hogy a csapat képes legyen minden rábízott feladatot önmaga ellátni, és ne kelljen külső segítséget kérnie az alapfeladatai elvégzéséhez. Így biztosítható a minél magasabb fokú autonómia és felelősségvállalás.

Diverzitás

➔ Barabási Albert-László kutatásai alapján tudjuk, hogy a kiemelkedő teljesítményű (high-performing) csapatok titka a csapattagok különbözőségében rejlik. Az előző pontban említett átfedő hard skillek akár gátló tényezők is lehetnek, ha a csapattagoknak nagyon hasonló a tudása és a háttere. Ebből következően szükséges, hogy különbözőek (is) legyünk. A különbözőségnek hard skillek, soft skillek és személyiségjegyek tekintetében is érdemes megmutatkoznia.

És egy jó vezető…

➔ Látható, hogy egy jól működő önszerveződő csapatban folyamatosan a csapatért kell dolgozni. A legtöbb szervezetben külön vezető felel azért, hogy a csapatok a munkafolyamataik és egyéni adottságaik tekintetében is fejlődhessenek. A SCRUM-ban például a scrummaster „feladata” az, hogy ezt a folyamatot elősegítse. Természetesen a scrummaster sem tud csodákat tenni, nincs is felhatalmazása az irányításra. Ha például a csapattagok motiválatlanok, és a csapat elé nincsenek inspiráló célok kitűzve, akkor igen nehéz önszerveződő csapatot építeni.

Az önszerveződő csapatokhoz illeszkedő vezetés eltér a hagyományos hierarchikus vezetéstől. A vezető szerepe kevéssé irányító jellegű, és inkább egy jó coachéhoz hasonlítható, aki segít a csapattagoknak és magának a csapatnak is a fejlődésben. Segít a csapattagoknak a célok definiálásában, tükröt tart eléjük, kérdéseket tesz fel, közelebb hozza a csapattagokat egymáshoz, és ha arra kerül a sor, challenge-eli is őket… Időnként taníthat is valami újat, hiszen lehet, hogy szükség van bizonyos hard skillek/soft skillek elsajátítására is, amivel kapcsolatban éppenséggel a csapat nagy segítségére lehet. A csapatot lelkesíteni is tudja, és gyakran pozitív visszajelzéseket fogalmaz meg. Ez a típusú vezető abban is igyekszik segíteni, hogy a csapat a környezetével is együtt tudjon működni, ami a csapat tevékenységi körén kívül eső szükségszerűség is lehet.

Fontos azonban, hogy ez a vezető is folyamatosan szem előtt tartsa, hogy a csapat ne függjön tőle hosszú távon, és ne neki akarjon megfelelni. Ezért a csapatnak a tőle való függőségét folyamatosan le kell építenie, hogy minél inkább önjáróan tudjon működni.

A szakirodalom kétféle vezetői stílust említ, ami passzol ehhez a vezetői szerephez: servant leadership és host leadership.

(Folyt. köv.)

<a href="https://agiluu.hu/author/istvan/" target="_self">Marhefka István</a>

Marhefka István

9 éves koromban kezdtem a programozást, professzionálisan pedig több mint 20 év tapasztalattal rendelkezem szoftvertermékek kifejlesztésében. Jónéhány agilis csapatban dolgoztam különféle szerepkörökben (vezető szoftverfejlesztő, architect, termékfelelős, scrum master stb.), ahol az erős csapatmunkára építve hoztunk létre sikeres termékeket. Dolgoztam magyar KKV-knál, multiknál Magyarországon és Svájcban. Korábbi saját startupom, az amerikai irodát is működtető Be-novative nevű cég, amelyből már exiteltem, a mai napig sikeres. Agilis szervezetfejlesztői és DevOps tanácsadóként 2017 óta dolgozom. Elsősorban hazai kkv-k és nagyvállalatok agilis és digitális transzformációs törekvéseit támogatom.

Az Agiluu támogatja a szervezeteket, hogy agilisabbá váljanak.

Tetszett az írás? Iratkozz fel a blogra, hogy mindig értesülj az új írásokról!