…tingene fungerer godt, da alle bare gør det, der skal gøres, af ren lidenskab, så problemfrit, at en iagttager kunne konkludere, at alle har evnen til at læse hinandens tanker. Men efterhånden som organisationen og produktet vokser, vokser også mængden af oplysninger, som teamene skal beherske, håndtere og dele for at få deres arbejde udført. Beslutninger bliver mere følsomme over for konteksten (for både teams og produkter) med en kompleksitet, der kræver en eller anden form for struktur for at holde tingene i gang, efterhånden som organisationen modnes. Du søger en organisationsstruktur, der optimerer teamets evne til at få tingene gjort for at skabe den største værdi.

✥ ✥ ✥

Effektiv kommunikation og feedback er kernen i effektiv udvikling af komplekse systemer, og organisationsstrukturen bør være optimeret til de mest afgørende kommunikationsveje. Kommunikation og regelmæssig feedback er sammen med selvorganisering det agile hjerte. Samspillet mellem mennesker med forskellige, tværgående interesser ligger i hjertet af innovation ().

Udviklingshold, der arbejder med komplekse produkter, kæmper hele tiden med den dobbelte natur af funktion og form. Vi har en tendens til at skabe grænser mellem udviklingsaktiviteter og organisatoriske enheder langs disse linjer. Men funktion og form er blot socialt konstruerede og noget arbitrære kategorier: pålidelighed kan være et lige så tvingende anliggende for et givet system, mens skønhed, bagudkompatibilitet eller et andet anliggende kan dominere en given udviklingsindsats. I hvert enkelt tilfælde vil forretningen være bedst tjent, hvis udviklingsteamet organiserer sig omkring de mest afgørende forretningsmæssige bekymringer – uanset hvad de måtte være.

Når dit team lige begynder at modnes i sine tidlige dage og begynder at bevæge sig i retning af at opbygge et Scrum-team, har du flere personer, der bekvemt kan arbejde som én organisatorisk enhed for at dække alle funktioner i en forretning (udgivelsesplanlægning, udvikling og faglig udvikling). Men vækst og modenhed medfører også ubehag, da teams længes efter den ustrukturerede effektivitet fra de enkle dage med uformelt arbejde. Men for at vokse og for at kunne forvalte produktet korrekt på markedet er det nødvendigt med en noget disciplineret organisationsstruktur og en vis let styring.

Kulturer har et iboende behov for struktur for at få helheden til at fungere effektivt. Den mest effektive kommunikation sker altid lokalt inden for det velkendte område, så det er afgørende at lokalisere beslutningsprocessen omkring de mest afgørende organisatoriske anliggender. Det er vigtigt i enhver ikke-triviel social organisation, at folk hurtigt kan forbinde et givet interesseområde med det mest effektive “sted at gå hen”, når de har brug for oplysninger om dette område eller skal foretage en handling på dette område.

En simpel organisatorisk opdeling (dvs. et hierarki) er nok i simple områder, der kun skal håndtere et sæt adskilte interesser. Men den hierarkiske fremgangsmåde bryder sammen i det mere typiske tilfælde af udviklingsindsatser med flere overlappende bekymringer. Dette presser på i retning af større, mere komplekse organisatoriske enheder, der forsøger at løse problemet med besparelser i omfanget. Alligevel er de mest effektive arbejdshold små teams, og man er nødt til at opdele arbejdet på en eller anden måde.

Hvorom alting er, er intet team en ø, og en udviklingsnation er mere end en samling af øer. Teams udvikler individuelt deres egen identitet, hvor en naturlig følelse af xenofobi (behov for det velkendte) får teams til kun at give sekundær status til bekymringer, der kommer uden for deres sociale kreds. Hvis man begrænser virksomheden til ét sæt sociale interaktioner baseret på en enkelt simpel opdeling, lukker man af for de ideer uden for grænserne, som giver næring til innovation.

Den hurtige beslutningstagning er altafgørende. Nogle spørgsmål er presserende (“Vi bliver angrebet af en anden stamme og må sætte et forsvar op mod dem”), mens andre, selv om de er vigtige, tåler eller endog beder om længere overvejelser (“Hvad er den bedste placering for den nye mødesal?”). Udtrykket “shearing layers” beskriver beslægtede processer, der bevæger sig med forskellige hastigheder, efter begrebet om tektoniske plader, der bevæger sig over hinanden, som f.eks. op til et jordskælv. Både bygningsarkitekter () og inden for softwarearkitektur (se ) har taget udtrykket til sig for at beskrive strukturer eller problemer med forskellige forandringshastigheder i et tæt koblet system. En virksomhed bør strukturere sin organisation således, at den hurtigt kan reagere på problemer i den første kategori uden at ødelægge sin effektivitet i forhold til problemer i den anden kategori.

Et andet agilt princip er, at vi er udadvendte: det vil sige, at vores fokus og bekymring er rettet mod slutbrugeren, markedet og kunderne snarere end mod de værktøjer og teknologier, vi bruger til at udføre vores arbejde. Organisationen bør også afspejle denne bekymring, da den er afgørende for værditilbuddet og opbygningen af hele udviklingsværdistrømmen.

I sidste ende bør organisationens struktur have lige så meget at gøre med processens struktur som produktets struktur.

Derfor,

Organiser arbejdsstyrken i små teams på mere eller mindre fem personer, der er opdelt efter de vigtigste bekymringer for virksomhedens værdiskabelse. Suppler denne struktur med et lille antal tværgående strukturer for sekundære, men vigtige anliggender, idet man aldrig glemmer, at disse strukturer kun er optimeringer i et ellers åbent miljø med ubegrænset samarbejde.

Tænk på en virksomhed, der er ved at bygge en mobiltelefon. De kan organisere deres Scrum-teams omkring de vigtigste leverancer eller tilkøbsmuligheder. Der kan således være et team til adressebogen, et andet til kalenderen og et andet til den mere traditionelle telefonfunktionalitet: se Værdiområde. Det er forretningens primære interesser. Men der kan også være grupper, der mødes for at definere praksis, politikker og virksomhedsstandarder (f.eks. brugergrænsefladens udseende), og som består af repræsentanter fra hvert Scrum Team. Disse grupper udvikler ikke produkter, men tjener som informationsudveksling og som kilder til standarder, der styrer udviklingen. I sunde organisationer er der næsten fuldstændig overlapning mellem medlemskabet af disse sidstnævnte grupper og udviklingsteamets medlemskab.

I de fleste miljøer afspejler den primære organiseringsstruktur den primære interessentstruktur, som normalt er markedet. Af denne grund organiserer vi ikke Scrum Teams langs partitionering af interne artefakter, heller ikke efter loci af domæneekspertise, men snarere langs linjerne af markedsleverancer som f.eks. funktioner. Organisering omkring features eller andre markedsleverancer er også en fordel for markedets reaktionsevne og reduceret time-to-market, fordi teamet er stedet for alt det arbejde, der er nødvendigt for at implementere en feature. På den måde holdes koordineringen inden for en organisatorisk grænse. Hvis arbejdsundergrupper eller kernekompetencer styrer den organisatoriske struktur, vil ændringer i markedet eller i leverancens art sandsynligvis medføre koordinering mellem flere teams eller organisationer – hvilket reducerer reaktionsevnen og øger beslutningstiden.

Hvis dette er den eneste struktur, understøtter den kun markedssynet, og den marginaliserer et væld af andre gyldige forretningshensyn. Hvis denne struktur skal fungere, skal den suppleres med tværgående strukturer, der understøtter et andet niveau af kommunikationseffektivitet, f.eks. strukturer, der er relateret til kernekompetencerne. Derfor optræder dette mønster næsten altid sammen med et mønster som “Birds of a Feather” og det mønster, der er beskrevet i “Domain Expertise in Roles”. Den organisatoriske rollestruktur skærer igennem de mure, der naturligt dannes mellem teams. Få produktindsatsen i en virksomhed til at forbinde sig med hinanden og med den øverste ledelse gennem MetaScrum. Teams, der har udviklet en vis grad af teamstolthed (se Team Pride), vil være mere effektive, da dette eller en anden tilsvarende kraft vil tilskynde til ansvarlighed. Dette er med til at sikre, at disse strukturer forbliver i spil på trods af de fremmedfjendske virkninger af holdmedlemskab.

Binde det hele sammen med et åbent miljø uden mure og uden døre. Udviklingsteams er enheder, der udelukkende består af udviklingsforpligtelser, og der bør ikke være nogen indblanding, der begrænser det frie samarbejde mellem udviklere på tværs af teams. Tilføj små rum i nærheden til korte perioder med stille, seriøs refleksion og små møder.

Alle værdikomponenter er fair game som et organiserende kriterium. For eksempel værdsætter Scrum i høj grad kollokation af teammedlemmer, så de mest grundlæggende organisatoriske grænser vil sandsynligvis svare til Collocated Teams.

✥ ✥ ✥

Bemærk, at der er to niveauer af Conways lov i et godt Scrum: et niveau drevet af fokus på produktet og et andet niveau drevet af fokus på kompetenceområder. På det overfladiske niveau organiserer vi teamet efter processen; det er den primære bekymring for både de indadvendte og udadvendte aspekter af processen. Så de tre sfærer med procesherredømme er:

• udviklingsteamet, som ejer beslutninger om den passende brug af teknologi og teknik i opbygningen af produktet;
• produktets ejer, som ejer definitionen og retningen af produktet; og,
• scrummasteren, som er ansvarlig for, at processen understøtter udviklingsteamets regelmæssige levering.

Scrum-udviklingsteams er feature-(produkt)teams. Det vil sige, at det primære organiseringsprincip for et Scrum-team er, at det er på linje med et tog af funktionsleverancer langs en værdistrøm. Der er en svag, overfladisk hierarkisk organisation inden for Scrum, der rummer flere udviklingsteams inden for hver produktudvikling, der deler en fælles Product Owner, i en organisation kaldet en Scrum of Scrums. Hvert udviklingsteam inden for en enkelt produktudvikling bygger et sæt funktioner ad gangen. Med tiden vil vigtige forretningsdrivere, fælles forretningsviden og værdistrømsartefakter binde disse funktioner sammen. Der er ingen anerkendte titler eller underopdelinger inden for udviklingsteamet.

Der er mange måder at opdele arbejdet i feature teams på. Et udviklingsteam kan levere funktioner til et givet marked (se “Organization Follows Market”) eller udvikle et produkt til en delmængde af virksomhedens teknologispektrum (et team til telefoner og et andet til tablets, selv om begge deler meget af den samme software). Generelt bør hvert team dannes omkring et produkt, der tegner sig for en del af virksomhedens værdi: se også Value Stream Fork. Scrum fraråder dog en udviklingsteamstruktur, hvor hvert team ejer en del af produktet eller blot en del af produktet. Hvis medlemmerne af et enkelt team kun kan udvikle én del af systemet, skal de koordinere flere udviklingsbeslutninger med de andre teams. Det bliver svært for holdene at træffe beslutninger lokalt, og resultatet er bl.a. forsinket feedback og handoffs.

På det andet niveau af Conways lov inden for Scrum organiserer folk sig omkring kompetenceområder, hvor dygtighed skaber værdi. Disse Birds of a Feather hjælper medlemmerne med at uddybe deres facilitet inden for et professionelt eller teknisk område, mens de deler idéer eller tager uddannelse. De fleste mennesker har et medfødt ønske om at forbedre sig (se ), og disse grupper giver næring til individuel stolthed, efterhånden som teammedlemmerne lærer og vokser. Men igen, disse grupper udgør ikke en rapporteringsstruktur, og ethvert teammedlem kan tilhøre flere Birds of a Feather samt sit eget Scrum Team. Se også domæneekspertise i roller.

Udviklingsteamets grænser og identitet samt Scrum Team-grænser og identitet er eksplicitte. Begrebet teamidentitet er afgørende for Team Pride og for organisationens effektive drift, da teamidentitet tilfører den sociale kontekst, der hjælper med at optimere beslutningstagningen. Ethvert begreb om organisatorisk identitet ud over disse to bør være stiltiende snarere end eksplicit eller administreret. Igen er der ingen formelle titler i udviklingsteamet ud over “udvikler”. Hvis der kun er én ukrænkelig regel, er det, at ingen enkeltperson kan bruge sin stiltiende ekspertise til at tilsidesætte en konsensus i teamet eller på anden måde forringe teamets samarbejdsånd, som i The Spirit of the Game. En i fællesskab udviklet Norms of Conduct er et stærkt forvarsel om teamets identitet.

Der kan være ekspertise i roller på individniveau, men det er vigtigt at supplere dette mønster med tværfunktionelle teams, hvor det er muligt, for at optimere muligheden for lokal beslutningstagning.

Den oprindelige Conway’s Law kom ud af software (se , s. 28-31). Der er mange myter forbundet med oprindelsen og praksis af Conway’s Law. Det blev længe hævdet, at objektorientering understøttede Conways lov ved at lokalisere markedsproblemer inde i klasser. Det er halvt sandt; klasser har en tendens til at indkapsle de langsigtede bekymringer i forbindelse med organisatoriske kernekompetencer. Objektorientering synes dog at fokusere på forbindelsen mellem udviklernes ekspertise og de artefakter, de udvikler, snarere end på forbindelsen til markedet eller til brugssager. Bekymringer for tilpasning til markedsstrukturen bør overtrumfe bekymringer for udviklernes verdensbillede af deres proces og produkt.

Den vandfaldslignende udviklingsstil har haft sin storhedstid. I vandfaldsorganisationer fulgte den primære organisatoriske struktur processtadier: behovsanalyse, design, implementering og test (, s. 1-9). I henhold til Conway’s lov afspejlede organisationsstrukturen disse proceshensyn. Softwaren kan meget vel også afspejle disse faser: f.eks. vil en serviceorienteret arkitektur (SOA) dokumentere de fleste af de værdiskabende krav i laget for serviceintegration, mens de enkelte tjenester findes i et andet lag. Waterfall lægger alle funktioner i udviklernes hænder på én gang, hvilket understøtter ræsonnementer om interaktioner mellem funktioner. Mens man i vandfaldstiden forsøgte at bringe markedshensyn (use cases) i overensstemmelse med arkitekturen, gik den organisatoriske struktur på tværs af denne taksonomi. Det samme kan siges om samlebåndsorganisation i fabrikker.

Da udviklingsteams er feature teams, bør de fokusere på én feature ad gangen (som i Swarming). Scrums primære markedsleverance er en feature, og i den forstand er der en god tilpasning mellem teamstrukturen og markedet. Scrum er tavs om produktarkitekturens form, men i den agile ånd er der en tendens til at fraråde individuelt kodeejerskab. Hvert udviklingsteam har licens til at arbejde på enhver del af produktet. Vi kan sige, at Scrum balancerer de organisatoriske fordele ved indkapsling med fordelene ved at tilpasse teamet til markedsleverancen. Product Owner styrer med støtte fra udviklingsteamet, hvordan man håndterer interaktioner mellem funktioner, der opstår over tid.

Tænk f.eks. på, at et team kan implementere funktionen Call Waiting til et telekommunikationssystem, mens et andet team implementerer Call Forwarding. På grund af fremkomsten kan man ikke altid forudse omkostningerne ved at løse afhængigheder mellem to givne Product Backlog Items (PBI’er), så det er generelt umuligt at løse dette problem ved at tildele PBI’er til teams. Under alle omstændigheder kan en for tidlig tildeling af arbejde til teams gøre det umuligt for folk at arbejde effektivt med de svære dele (især dem, der er relateret til interaktionen mellem delene) og begrænser selvorganisering på Scrum Team-niveau. De to funktioner kan være meget afhængige af hinanden, men Scrum-strukturen giver ikke disse interaktioner førsteklasses status. I dette tilfælde ville det sandsynligvis være bedre, hvis et enkelt team udviklede begge funktioner. Hvordan man tildeler arbejdet til teams bygger på løbende planlægning og fælles beslutningstagning, der starter med Sprint Planning. Et godt Scrum-team stræber efter at fordele arbejdet på tværs af udviklingsteams gennem intime, men tidsmæssigt afgrænsede, interaktioner mellem Product Owner og udviklingsteamet, som i begivenheder for løbende at genetablere en Refined Product Backlog samt gennem Sprint Planning.

Ledelse er normalt en del af den organisatoriske blanding, selv om der er nogle Scrum-udviklinger, der kører uden ledere (se f.eks. den nylige video om den agile transformation hos Bosch Software Innovations. ) Scrum-ethos har en tendens til at fokusere på mennesker og produkt, og fokus er legemliggjort i Scrum-rollerne og de organisationer (som udviklingsteamet og Product Owner Team), som de repræsenterer. Hvis en organisation med allerede eksisterende ledere går i gang med at indføre Scrum, er det alt for nemt for Scrum-indsatsen at afvise ledelsesdelen af organisationen som noget andet end den anden verden. I sådanne situationer, hvor en ledelsesfri organisation ikke er en mulighed, er det afgørende at inddrage lederne.

Steven Johnson. Hvor gode ideer kommer fra. New York: Riverhead Trade, 2011.

Stewart Brand. How Buildings Learn: What Happens After They’re Built. New York: Penguin, 1995.

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

Daniel Pink. Drive: Den fantastiske sandhed om, hvad der motiverer os. New York: Riverhead Books, 2011.

Melvin E. Conway. “How do committees invent?ˮ I 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. (Oprindeligt udgivet af TRW.)

Bosch Software Innovations. “Lessons learned”: Agile organisation hos Bosch Software Innovations. ˮ YouTube.com, 15. juni 2018, https://www.youtube.com/watch?v=CwodQs7D8BY.

Billedkredit: Billeder leveret af PresenterMedia.com.