…a dolgok jól működnek, hiszen mindenki csak teszi, amit tennie kell, tiszta szenvedélyből, olyan zökkenőmentesen, hogy egy megfigyelő arra a következtetésre juthat, hogy mindenki képes olvasni a másik gondolataiban. Ahogy azonban a szervezet és a termék növekszik, úgy nő az információ mennyisége is, amelyet a csapatoknak el kell sajátítaniuk, kezelniük és megosztaniuk kell a munkájuk elvégzéséhez. A döntések egyre érzékenyebbé válnak a kontextusra (mind a csapatok, mind a termékek esetében), és ez a komplexitás valamiféle struktúráért könyörög, hogy a dolgok zökkenőmentesen működjenek, ahogy a szervezet érik. Olyan szervezeti struktúrát keres, amely optimalizálja a csapat képességét a dolgok elvégzésére a Legnagyobb Érték létrehozása érdekében.

✥ ✥ ✥ ✥

A hatékony kommunikáció és a visszajelzés áll a hatékony komplex rendszerfejlesztés középpontjában, és a szervezeti struktúrát a kommunikáció legfontosabb útjaira kell optimalizálni. A kommunikáció és a rendszeres visszajelzés az önszerveződéssel együtt az agilis szívét alkotja. Az innováció középpontjában a különböző, több területet érintő kérdésekkel foglalkozó emberek interakciója áll ().

A komplex termékeken dolgozó fejlesztőcsapatok folyamatosan küzdenek a funkció és a forma kettős természetével. Hajlamosak vagyunk a fejlesztési tevékenységek és a szervezeti egységek közötti határokat e mentén kialakítani. Pedig a funkció és a forma csak társadalmilag konstruált és némileg önkényes kategóriák: a megbízhatóság ugyanolyan kényszerítő szempont lehet egy adott rendszer esetében, míg a szépség, a visszafelé kompatibilitás vagy más szempontok dominálhatnak egy adott fejlesztési erőfeszítésben. Az üzletet minden esetben az szolgálja a legjobban, ha a fejlesztőcsapat a legfontosabb üzleti aggályok köré szerveződik – bármi legyen is az.”

Amint a csapat éppen csak kezd érni a kezdeti időkben, és kezd a Scrum-csapat kialakítása felé haladni, már több ember van, akik kényelmesen, egy szervezeti egységként dolgozva lefedhetik az összes üzleti funkciót (kiadástervezés, fejlesztés és szakmai fejlődés). A növekedés és az érettség azonban kényelmetlenséget is okoz, mivel a csapatok visszavágynak az informális munka egyszerű napjainak strukturálatlan hatékonyságára. Pedig a növekedéshez és a termék megfelelő piaci menedzseléséhez némileg fegyelmezett szervezeti struktúrára és némi könnyed irányításra van szükség.

A kultúráknak eredendően szükségük van a struktúrára az egész hatékony működéséhez. A leghatékonyabb kommunikáció mindig helyben, az ismerősök birodalmában történik, ezért döntő fontosságú a döntéshozatali folyamat lokalizálása a legfontosabb szervezeti kérdések körül. Bármely nem triviális társadalmi szervezetben fontos, hogy az emberek bármely adott érdekeltségi területhez gyorsan hozzárendelhessék a leghatékonyabb “helyszínt”, ha információra van szükségük az adott területről, vagy ha az adott területen kell cselekedniük.

Az egyszerű szervezeti felosztás (azaz a hierarchia) elegendő az olyan egyszerű területeken, ahol csak egy sor elválasztható érdekeltséggel kell foglalkozni. A hierarchikus megközelítés azonban összeomlik a többszörösen átfedő aggályokkal járó fejlesztési erőfeszítések tipikusabb esetében. Ez a nagyobb, összetettebb szervezeti egységek felé tolódik, amelyek a hatókör megtakarításával próbálják orvosolni a problémát. Pedig a leghatékonyabb munkacsoportok kiscsapatok, és valahogyan fel kell osztani a munkát.

Mindenesetre egyetlen csapat sem sziget, és egy fejlesztő nemzet több, mint szigetek gyűjteménye. A csapatok egyénileg alakítják ki saját identitásukat, ahol a természetes idegengyűlölet (az ismerős iránti igény) arra készteti a csapatokat, hogy csak másodlagos jelentőséget tulajdonítsanak a társadalmi körükön kívülről érkező aggodalmaknak. Ha a vállalkozást egyetlen egyszerű felosztáson alapuló társadalmi interakciókra korlátozza, akkor elzárja a határokon kívüli ötleteket, amelyek az innovációt táplálják.

A döntéshozatal gyorsasága a legfontosabb. Egyes kérdések sürgősek (“Egy másik törzs megtámadott bennünket, és védekezni kell ellenük”), míg mások, bár fontosak, elviselik a hosszabb mérlegelést, sőt könyörögnek érte (“Mi a legjobb hely az új tárgyalóteremnek?”). A nyíró rétegek kifejezés az egymáshoz kapcsolódó, különböző sebességgel mozgó folyamatokat írja le, az egymáson áthaladó tektonikus lemezek fogalma után, amelyek például földrengéshez vezetnek. Mind az épületépítészek (), mind a szoftverarchitektúra területe (lásd ) átvette a kifejezést, hogy egy szorosan összekapcsolt rendszerben eltérő sebességgel változó struktúrákat vagy problémákat írjon le. Egy vállalatnak úgy kell felépítenie a szervezetét, hogy képes legyen gyorsan reagálni az első kategóriába tartozó problémákra anélkül, hogy a második kategóriába tartozó problémák esetében tönkretenné a hatékonyságát.

Egy másik agilis alapelv, hogy kifelé tekintünk: vagyis a végfelhasználóra, a piacra és az ügyfelekre összpontosítunk, és nem a munkánk elvégzéséhez használt eszközökre és technológiákra. A szervezetnek is tükröznie kell ezt az aggodalmat, mivel ez a kulcs az értékfelvetés és a fejlesztés teljes értékáramának felépítése szempontjából.

A szervezet felépítésének végül ugyanannyi köze kell legyen a folyamat felépítéséhez, mint a termék felépítéséhez.

Ezért,

szervezzük a munkaerőt több-kevesebb ötfős kiscsapatokba, amelyek a vállalkozás értékteremtése szempontjából legfontosabb aggodalmak szerint vannak felosztva. Egészítse ki ezt a struktúrát kisszámú, a másodlagos, de fontos kérdésekre vonatkozó, átfogó struktúrával, soha nem feledve, hogy ezek a struktúrák csak optimalizálások az egyébként nyílt, korlátlan együttműködésre épülő környezetben.

Gondoljunk egy mobiltelefont építő vállalkozásra. Lehet, hogy a Scrum-csapatokat a főbb teljesítmények vagy megvásárolható opciók köré szervezik. Így lehet egy csapat a címjegyzékre, egy másik a naptárra, és egy másik a hagyományosabb telefonfunkciókra: lásd Értékterület. Ezek az üzlet elsődleges szempontjai. De lehetnek olyan csoportok is, amelyek a gyakorlatok, irányelvek és vállalati szabványok (pl. a felhasználói felület megjelenése) meghatározására jönnek össze, és az egyes Scrum-csapatok képviselőiből állnak. Ezek a csoportok nem készítenek terméket, hanem információcserére és a fejlesztést irányító szabványok forrásaként szolgálnak. Az egészséges szervezetekben ez utóbbi csoportok tagsága és a fejlesztőcsapatok tagsága között szinte teljes átfedés van.

A legtöbb környezetben az elsődleges szervezeti struktúra az elsődleges érdekeltek struktúráját tükrözi, ami általában a piac. Emiatt a Scrum-csapatokat nem a belső artefaktumok felosztása mentén szervezzük, sem a domain-szakértelem lokalizációja szerint, hanem inkább a piaci teljesítmények, például a funkciók mentén. A funkciók vagy más piaci teljesítmények köré szerveződés a piaci reagálóképességnek és a piacra jutási idő csökkentésének is kedvez, mivel a csapat a funkció megvalósításához szükséges összes munka helyszíne. Ezáltal a koordináció egy szervezeti határon belül marad. Ha a szervezeti struktúrát a munka részegységek vagy az alapvető kompetenciák határozzák meg, akkor a piacon vagy a teljesítendő termék jellegében bekövetkező változások valószínűleg több csapat vagy szervezet közötti koordinációt vonnak maguk után – ami csökkenti a reagálóképességet és növeli a döntéshozatali időt.

Ha ez az egyetlen struktúra, akkor csak a piaci szemléletet támogatja, és számos más érvényes üzleti szempontot háttérbe szorít. Ahhoz, hogy ez a struktúra működjön, ki kell egészíteni olyan átfogó struktúrákkal, amelyek a kommunikáció hatékonyságának egy második szintjét támogatják, pl. az alapkompetenciákhoz kapcsolódó struktúrákkal. Ez a minta tehát szinte mindig együtt jelenik meg egy olyan mintával, mint a Birds of a Feather és a Domain Expertise in Roles-ban leírt mintával. A szervezeti szerepstruktúra átvágja a csapatok között természetesen kialakuló falakat. A vállalaton belüli terméktörekvéseket arra ösztönzi, hogy a MetaScrumon keresztül kapcsolódjanak egymáshoz és a vezetőséghez. Azok a csapatok, amelyekben kialakult egyfajta csapatbüszkeség (lásd Csapatbüszkeség), hatékonyabbak lesznek, mivel ez vagy valamilyen más egyenértékű erő ösztönzi a felelősségvállalást. Ez segít abban, hogy ezek a struktúrák a csapattagság idegengyűlölő hatása ellenére is működőképesek maradjanak.

Kössük össze az egészet egy nyitott környezettel, ahol nincsenek falak és ajtók. A fejlesztői csapatok csak a fejlesztési elkötelezettség egységei, és nem szabad, hogy a csapatok közötti szabad együttműködést korlátozó beavatkozás legyen a fejlesztők között. Adjon a közelben kis helyiségeket a nyugodt, komoly elmélkedés és kisebb megbeszélések rövid idejére.

Az érték bármely összetevője szervezési kritériumként fair játék. A Scrum például nagyra értékeli a csapattagok kollokációját, így a legalapvetőbb szervezeti határok valószínűleg a kollokált csapatoknak felelnek meg.

✥ ✥ ✥ ✥

Megjegyezzük, hogy egy jó Scrumban a Conway-törvénynek két szintje van: az egyiket a termékre való összpontosítás vezérli, a másikat pedig a kompetenciaterületekre való összpontosítás. A felszíni szinten a folyamat szerint szervezzük a csapatot; ez az elsődleges szempont mind a folyamat befelé, mind a kifelé irányuló aspektusait illetően. Tehát a folyamat uralmának három szférája a következő:

• a fejlesztőcsapat, aki a termék építése során a technológia és a technika megfelelő alkalmazásával kapcsolatos döntések tulajdonosa;
• a terméktulajdonos, aki a termék meghatározásának és irányának tulajdonosa; és,
• a ScrumMaster, aki felelős azért, hogy a folyamat támogassa a fejlesztőcsapat rendszeres teljesítését.

A Scrum fejlesztőcsapatok funkció (termék) csapatok. Ez azt jelenti, hogy a Scrum-csapat elsődleges szervezőelve az, hogy egy értékfolyam mentén a funkciószállítások vonulatához igazodik. A Scrumon belül létezik egy gyenge, sekély hierarchikus szerveződés, amely minden termékfejlesztésen belül több Fejlesztőcsapatot is befogad, amelyeknek közös Terméktulajdonosuk van, egy Scrum of Scrumnak nevezett szervezetben. Egy termékfejlesztésen belül minden egyes fejlesztőcsapat egyszerre egy-egy funkciócsoportot épít. Idővel a kulcsfontosságú üzleti ösztönzők, a megosztott üzleti tudás és az értékáramlási artefaktumok összekötik ezeket a funkciókat. A Fejlesztési Csapaton belül nincsenek elismert címek vagy alosztályok.

A munka feature-csapatokra történő felosztásának számos módja van. Egy fejlesztőcsapat szállíthat funkciókat egy adott piacra (lásd: A szervezet követi a piacot), vagy fejleszthet terméket a vállalati technológiai spektrum valamely részhalmazára (egy csapat a telefonokra, egy másik a táblagépekre, bár mindkettő nagyrészt ugyanazt a szoftvert használja). Általánosságban elmondható, hogy minden csapatnak olyan termék köré kell szerveződnie, amely a vállalati érték egy komponensét képviseli: lásd még Értékfolyam-villa. A Scrum azonban ellenzi az olyan fejlesztőcsapat-struktúrát, ahol minden csapat a termék egy részét vagy csak egy termékrészletet birtokol. Ha bármelyik csapat tagjai csak a rendszer egy részét fejleszthetik, akkor több fejlesztési döntést kell összehangolniuk a többi csapattal. A csapatok számára nehézzé válik a helyi döntések meghozatala, és az eredmények közé tartozik a késleltetett visszajelzés és átadás.

A Conway-törvény második szintjén a Scrumon belül az emberek olyan kompetenciaterületek köré szerveződnek, amelyekben a jártasság értéket teremt. Ezek a Madarak segítenek a tagoknak elmélyíteni a létesítményüket valamilyen szakmai vagy technikai területen, miközben ötleteket osztanak meg egymással vagy képzéseken vesznek részt. A legtöbb emberben veleszületett vágy van a fejlődésre (lásd ), és ezek a csoportok táplálják az egyéni büszkeséget, miközben a csapattagok tanulnak és fejlődnek. De ismétlem, ezek a csoportok nem képeznek jelentési struktúrát, és bármelyik csapattag tartozhat több Birds of a Feather-hez is, valamint a saját Scrum-csapatához. Lásd még a Domain szakértelem a szerepeknél.

A fejlesztőcsapatok határai és identitása, valamint a Scrum-csapatok határai és identitása egyértelműek. A csapatidentitás fogalma kulcsfontosságú a csapatbüszkeség és a szervezet hatékony működése szempontjából, mivel a csapatidentitás hozza azt a társadalmi kontextust, amely segít a döntéshozatal optimalizálásában. A szervezeti identitás e kettőn túli bármely fogalmának inkább hallgatólagosnak, mintsem explicitnek vagy adminisztráltnak kell lennie. Ismétlem, a fejlesztőcsapaton belül nincsenek formális címek a “Fejlesztő”-n kívül. Ha csak egyetlen sérthetetlen szabály van, akkor az az, hogy egyetlen egyén sem használhatja fel hallgatólagos szakértelmét arra, hogy felülírja a csapat konszenzusát, vagy bármilyen más módon csökkentse a csapatmunka szellemét, mint A játék szellemében. A közösen kialakított magatartási normák a csapatidentitás erős előjele.

A szerepekben egyéni szinten is lehet szakértelem, de fontos, hogy ezt a mintát lehetőség szerint keresztfunkcionális csapatokkal egészítsük ki, hogy optimalizáljuk a helyi döntéshozatal lehetőségét.

Az eredeti Conway-törvény a szoftverekből származik (lásd , 28-31. o.). A Conway-törvény eredetéhez és gyakorlatához számos mítosz kapcsolódik. Sokáig úgy tartották, hogy az objektumorientáció támogatja a Conway-törvényt azáltal, hogy a piaci szempontokat az osztályokon belül lokalizálja. Ez félig igaz; az osztályok általában a szervezeti magkompetencia hosszú távú aggodalmait foglalják magukba. Mégis úgy tűnik, hogy az objektumorientáció inkább a fejlesztők szakértelme és az általuk fejlesztett artefaktumok közötti kapcsolatra összpontosít, mint a piaccal vagy a használati esetekkel való kapcsolatra. A piaci struktúrához való igazodással kapcsolatos aggodalmaknak felül kell múlniuk a fejlesztők folyamatukról és termékükről alkotott világképével kapcsolatos aggodalmakat.

A fejlesztés vízeséses stílusának fénykorát élte. A vízeséses szervezetekben az elsődleges szervezeti struktúra a folyamat szakaszait követte: követelményelemzés, tervezés, megvalósítás és tesztelés (, pp. 1-9). Conway törvénye szerint a szervezeti struktúra tükrözte ezeket a folyamatkérdéseket. A szoftver nagyon is jól tükrözheti ezeket a fázisokat: például egy szolgáltatásorientált architektúra (SOA) a legtöbb értéknövelt követelményt a szolgáltatásintegrációs rétegben bizonyítja, míg az egyes szolgáltatások egy másik rétegben találhatók. A vízesés az összes funkciót egyszerre adja a fejlesztők kezébe, ami támogatja a funkciók közötti kölcsönhatásokról való gondolkodást. Míg a vízesés korszak szoftvertervezési megközelítései a piaci szempontokat (használati eseteket) próbálták összhangba hozni az architektúrával, a szervezeti struktúra átvágta ezt a taxonómiát. Ugyanez mondható el a gyárak futószalagos szervezéséről is.

Mivel a fejlesztőcsapatok funkciócsapatok, egyszerre egy-egy funkcióra kell koncentrálniuk (mint a Swarmingban). A Scrum elsődleges piaci hozadéka egy funkció, és ebben az értelemben jó az összhang a csapatszerkezet és a piac között. A Scrum hallgat a termékarchitektúra formájáról, de az agilis szellemében inkább elriasztja az egyéni kódtulajdonlást. Minden fejlesztőcsapatnak engedélye van arra, hogy a termék bármely részén dolgozzon. Azt mondhatjuk, hogy a Scrum egyensúlyt teremt a kapszulázás szervezeti előnyei és a csapat és a piaci eredmény összehangolásának előnyei között. A terméktulajdonos a fejlesztőcsapat támogatásával kezeli, hogyan kezelje az idővel felmerülő funkcióinterakciókat.

Mondjuk például, hogy az egyik csapat megvalósíthatja egy távközlési rendszer hívásvárakoztatási funkcióját, míg egy másik a hívásátirányítást. Az emergencia miatt nem mindig lehet előre látni a két adott Product Backlog Items (PBI) közötti függőségek megoldásának költségeit, így általában nem lehet ezt a problémát a PBI-k csapatokhoz rendelésével megoldani. Mindenesetre a munkák csapatokhoz való idő előtti hozzárendelése lehetetlenné teheti, hogy az emberek hatékonyan dolgozzanak a nehéz részeken (különösen a részek közötti kölcsönhatáshoz kapcsolódó részeken), és korlátozza az önszerveződést a Scrum-csapat szintjén. A két funkció nagymértékben függhet egymástól, de a Scrum struktúra nem ad első osztályú rangot ezeknek a kölcsönhatásoknak. Ebben az esetben valószínűleg jobb lenne, ha mindkét funkciót egyetlen csapat fejlesztené. A munka csapatok közötti elosztásának módja a folyamatos tervezésre és a közös döntéshozatalra épül, kezdve a Sprinttervezéssel. Egy jó Scrum-csapat arra törekszik, hogy a munkát a fejlesztőcsapatok között a terméktulajdonos és a fejlesztőcsapat közötti bensőséges, de időben behatárolt interakciók révén ossza fel, például a finomított termékhátralék folyamatos újrateremtésére irányuló események, valamint a Sprinttervezés révén.

A vezetés általában a szervezeti összetétel része, bár vannak olyan Scrum-fejlesztések, amelyek vezetők nélkül futnak (lásd például a Bosch Software Innovationsnál zajló agilis átalakulásról szóló friss videót. ) A Scrum-ethosz általában az emberekre és a termékre összpontosít, és ez a fókusz a Scrum-szerepekben és az általuk képviselt szervezetekben (például a fejlesztőcsapatban és a terméktulajdonos-csapatban) testesül meg. Ha egy olyan szervezet, ahol már léteznek menedzserek, nekilát a Scrum bevezetésének, túl könnyen előfordulhat, hogy a Scrum-törekvés túlviláginak tekinti a szervezet menedzsment részét. Ilyen helyzetekben, amikor a menedzsmentmentes szervezet nem jöhet szóba, elengedhetetlen a menedzserek bevonása.”

Steven Johnson. Honnan származnak a jó ötletek. New York: Riverhead Trade, 2011.

Stewart Brand. Hogyan tanulnak az épületek: What Happens After They’re Built. New York: Penguin, 1995.

Brian Foote és Joseph Yoder. “Big Ball of Mud.ˮ In Pattern Languages of Program Design 4, Brian Foote et al., szerk. London: Pearson, 2000.

Daniel Pink. Drive: Az elképesztő igazság arról, hogy mi motivál minket. New York: Riverhead Books, 2011.

Melvin E. Conway. “How do committees invent?ˮ In Datamation 14(4), April, 1968, pp. 28-31.

Dr. Winston W. Royce. “Managing the Development of Large Software Systems.ˮ In Proceedings IEEE WESCON, August 1970, pp. 1-9. (Eredetileg a TRW kiadványa.)

Bosch Software Innovations. “Tanulságok: Agilis szervezet a Bosch Software Innovationsnál. “ˮ YouTube.com, 2018. június 15., https://www.youtube.com/watch?v=CwodQs7D8BY.

Picture credits: A képeket a PresenterMedia.com bocsátotta rendelkezésre.