…de dingen goed gaan, omdat iedereen gewoon doet wat gedaan moet worden uit pure passie, zo naadloos dat een waarnemer zou kunnen concluderen dat iedereen het vermogen heeft om elkaars gedachten te lezen. Maar naarmate de organisatie en het product groeien, groeit ook de hoeveelheid informatie die teams moeten beheersen, beheren en delen om hun werk gedaan te krijgen. Beslissingen worden gevoeliger voor de context (van zowel de teams als de producten), met een complexiteit die smeekt om een soort structuur om dingen soepel te laten verlopen terwijl de organisatie volwassen wordt. U bent op zoek naar een organisatiestructuur die het vermogen van het team optimaliseert om dingen gedaan te krijgen om de Grootste Waarde te creëren.

✥ ✥ ✥

Effectieve communicatie en feedback zijn de kern van effectieve complexe systeemontwikkeling, en de organisatiestructuur moet worden geoptimaliseerd voor de meest cruciale communicatiepaden. Communicatie en regelmatige feedback vormen, samen met zelforganisatie, het wendbare hart. De interactie van mensen met uiteenlopende, transversale belangen ligt aan de basis van innovatie ().

Ontwikkelingsteams die werken aan complexe producten worstelen voortdurend met het duale karakter van functie en vorm. We hebben de neiging om grenzen te trekken tussen ontwikkelingsactiviteiten en organisatorische eenheden langs deze lijnen. Toch zijn functie en vorm slechts sociaal geconstrueerde en enigszins arbitraire categorieën: betrouwbaarheid kan net zo’n dwingende zorg zijn voor een bepaald systeem, terwijl schoonheid, achterwaartse compatibiliteit, of een andere zorg een bepaalde ontwikkelingsinspanning kan domineren. In elk geval is de business er het meest mee gediend als het ontwikkelteam zich organiseert rond de meest cruciale business concerns – wat die ook mogen zijn.

Als je team net volwassen begint te worden en begint toe te werken naar een Scrum Team, heb je meer mensen die handig als één organisatorische eenheid kunnen werken om alle functies van een bedrijf te bestrijken (releaseplanning, ontwikkeling en professionele groei). Maar groei en maturiteit veroorzaken ook ongemak, omdat teams terugverlangen naar de ongestructureerde doeltreffendheid van de eenvoudige dagen van informeel werken. Toch vereist groei en het goed managen van het product in de markt een enigszins gedisciplineerde organisatiestructuur en wat licht bestuur.

Culturen hebben een intrinsieke behoefte aan structuur voor het efficiënt functioneren van het geheel. De meest effectieve communicatie vindt altijd plaats binnen de vertrouwde sfeer, dus is het van cruciaal belang het besluitvormingsproces te lokaliseren rond de meest cruciale organisatorische aandachtspunten. Het is belangrijk in elke niet-triviale sociale organisatie dat mensen snel in staat zijn om elk gegeven domein van belang te associëren met de meest efficiënte “plaats om naar toe te gaan” wanneer zij informatie nodig hebben over dat gebied of actie moeten ondernemen op dat gebied.

Een eenvoudige organisatorische partitionering (d.w.z. een hiërarchie) is voldoende in eenvoudige domeinen die zich moeten bezighouden met slechts één set van deelbare zorgen. Maar de hiërarchische aanpak breekt af in het meer typische geval van ontwikkelingsinspanningen met veel overlappende zorgen. Dit duwt in de richting van grotere, complexere organisatorische eenheden die proberen om het probleem te corrigeren met economies of scope. Toch zijn de meest effectieve teams kleine teams, en je moet het werk op de een of andere manier verdelen.

Hoewel, geen team is een eiland, en een ontwikkelingsland is meer dan een verzameling eilanden. Teams ontwikkelen individueel hun eigen identiteit, waarbij een natuurlijk gevoel van xenofobie (behoefte aan het vertrouwde) ervoor zorgt dat teams slechts secundair belang hechten aan zorgen die van buiten hun sociale kring komen. Als u de onderneming beperkt tot één reeks sociale interacties, gebaseerd op één enkele eenvoudige partitionering, sluit u de ideeën buiten die innovatie aanwakkeren.

De snelheid van besluitvorming is van het grootste belang. Sommige kwesties zijn dringend (“We worden aangevallen door een andere stam en moeten een verdediging tegen hen opzetten,”) terwijl andere, hoewel belangrijk, een langere beraadslaging tolereren of zelfs smeken (“Wat is de beste locatie voor de nieuwe vergaderzaal?”). De term afschuivingslagen beschrijft verwante processen die met verschillende snelheden bewegen, naar het begrip van tektonische platen die over elkaar heen bewegen, zoals de aanloop tot een aardbeving. Zowel architecten van gebouwen () als het veld van de software-architectuur (zie ) hebben de uitdrukking overgenomen om structuren of aandachtspunten te beschrijven met verschillende snelheden van verandering in een strak gekoppeld systeem. Een bedrijf zou zijn organisatie zo moeten structureren dat het snel kan reageren op problemen in de eerste categorie zonder zijn effectiviteit te verliezen voor problemen in de tweede.

Een ander agile principe is dat we naar buiten gericht zijn: dat wil zeggen, onze focus en zorg zijn gericht op de eindgebruiker, markt en klanten in plaats van op de tools en technologieën die we gebruiken om ons werk te doen. De organisatie zou deze zorg ook moeten weerspiegelen, aangezien het de sleutel is tot het waardevoorstel en de bouw van de volledige Waardestroom van ontwikkeling.

Op het einde, zou de structuur van de organisatie evenveel te maken moeten hebben met de structuur van het proces als de structuur van het product.

Daarom,

Organiseer het personeel in Kleine Teams van min of meer vijf mensen, verdeeld volgens de belangrijkste zorgen voor de creatie van waarde door de onderneming. Vul deze structuur aan met een klein aantal transversale structuren voor secundaire maar belangrijke zorgen, nooit vergetend dat deze structuren slechts optimalisaties zijn in wat anders een open omgeving van onbeperkte samenwerking is.

Bedenk een onderneming die een mobiele telefoon bouwt. Zij zouden hun Scrum-teams kunnen organiseren rond de belangrijkste deliverables of koopbare opties. Zo kan er een team zijn voor het adresboek, een ander voor de kalender, en een ander voor de meer traditionele telefoonfunctionaliteit: zie Value Area. Dat zijn de primaire zorgen van het bedrijf. Maar er kunnen groepen zijn die samenkomen om praktijken, beleid, en bedrijfsnormen (b.v. de gebruikersinterface look and feel) te bepalen, bestaande uit vertegenwoordigers van elk Scrum Team. Deze groepen bouwen geen product, maar dienen als informatie-uitwisseling en als bron van standaarden die de ontwikkeling sturen. In gezonde organisaties is er bijna volledige overlap tussen het lidmaatschap van deze laatste groepen en het lidmaatschap van het ontwikkelingsteam.

In de meeste omgevingen weerspiegelt de primaire organisatiestructuur de primaire structuur van de belanghebbenden, die gewoonlijk de markt is. Om deze reden, organiseren wij Scrum Teams niet volgens de verdeling van interne artefacten, noch volgens de loci van domeinexpertise, maar eerder volgens de lijnen van markt deliverables zoals eigenschappen. Het organiseren rond features of andere markt deliverables is ook een zegen voor de marktresponsiviteit en verminderde time-to-market omdat het team de locus is van al het werk dat nodig is om een feature te implementeren. Dit houdt de coördinatie binnen een organisatorische grens. Als werksubassemblages of kerncompetenties de organisatiestructuur aansturen, dan zullen veranderingen in de markt of in de aard van de deliverable waarschijnlijk coördinatie tussen meerdere teams of organisaties met zich meebrengen – wat de reactiesnelheid vermindert en de besluitvormingstijd doet toenemen.

Als dit de enige structuur is, ondersteunt het alleen de marktvisie, en het marginaliseert een groot aantal andere geldige zakelijke belangen. Wil deze structuur werken, dan moet zij worden aangevuld met transversale structuren die een tweede niveau van communicatie-efficiëntie ondersteunen, b.v. die welke verband houden met de kernbekwaamheden. Daarom verschijnt dit patroon bijna altijd samen met een patroon zoals Vogels van een Veer en het patroon beschreven in Domeinexpertise in Rollen. De organisatorische rollenstructuur doorbreekt de muren die zich op natuurlijke wijze tussen teams vormen. Laat productinspanningen binnen een onderneming zich met elkaar en met het uitvoerend management verbinden door middel van het MetaScrum. Teams die een zekere mate van teamtrots hebben ontwikkeld (zie Teamtrots) zullen effectiever zijn, aangezien deze of een andere gelijkwaardige kracht verantwoordelijkheid zal aanmoedigen. Dit helpt ervoor te zorgen dat deze structuren in het spel blijven ondanks de xenofobe effecten van teamlidmaatschap.

Bind het allemaal samen met een open omgeving zonder muren en zonder deuren. Ontwikkelteams zijn alleen eenheden van ontwikkelinzet, en er mag geen inmenging zijn die de vrije samenwerking tussen ontwikkelaars over teams heen beperkt. Voeg kleine kamers in de buurt toe voor korte periodes van rustige, serieuze reflectie en kleine vergaderingen.

Elk onderdeel van waarde is eerlijk spel als een organiserend criterium. Scrum hecht bijvoorbeeld veel waarde aan de collocatie van teamleden, dus de meest basale organisatorische grenzen zullen waarschijnlijk overeenkomen met Collocated Teams.

✥ ✥ ✥

Merk op dat er twee niveaus van Conway’s Law in een goede Scrum zijn: een gedreven door een focus op het product, en een ander gedreven door een focus op competentiegebieden. Aan de oppervlakte organiseren we het team volgens het proces; dat is de primaire zorg voor zowel de naar binnen- als de naar buiten gerichte aspecten van het proces. Dus de drie sferen van procesheerschappij zijn:

• het Ontwikkelteam dat eigenaar is van beslissingen over het geschikte gebruik van technologie en techniek bij het bouwen van het product;
• de Product Eigenaar, die eigenaar is van de definitie en richting van het product; en,
• de ScrumMaster die er verantwoordelijk voor is dat het proces de reguliere oplevering van het Ontwikkelteam ondersteunt.

Scrum Ontwikkelteams zijn functie (product) teams. Dat wil zeggen, het primaire organiserende principe van een Scrum Team is dat het zich afstemt op een trein van kenmerkleveringen langs een Waardestroom. Er is een zwakke, ondiepe hiërarchische organisatie binnen Scrum die plaats biedt aan meerdere Development Teams binnen elke productontwikkeling, die een gemeenschappelijke Product Owner delen, in een organisatie die een Scrum van Scrums wordt genoemd. Elk Ontwikkelteam binnen een enkele productontwikkeling bouwt één set van eigenschappen tegelijkertijd. Na verloop van tijd, zullen de belangrijkste business drivers, gedeelde business kennis, en Value Stream artefacten deze eigenschappen samenbinden. Er zijn geen erkende titels of onderverdelingen binnen het Development Team.

Er zijn vele manieren om het werk te verdelen in feature teams. Een Development Team kan functies leveren aan een bepaalde markt (zie Organization Follows Market), of product ontwikkelen voor een deelverzameling van het bedrijfstechnologiespectrum (een team voor telefoons en een ander voor tablets, hoewel beide veel van dezelfde software delen). In het algemeen, zou elk team rond één of ander product moeten worden gevormd dat goed is voor een component van ondernemingswaarde: zie ook Value Stream Fork. Scrum ontmoedigt echter een Development Team structuur waar elk team één deel van het product bezit, of slechts een subassemblage van het product. Als de leden van één enkel team slechts één deel van het systeem kunnen ontwikkelen, dan zullen zij meer ontwikkelingsbeslissingen moeten coördineren met andere teams. Het wordt moeilijk voor teams om lokaal beslissingen te nemen, en de resultaten omvatten vertraagde terugkoppeling en handoffs.

Op het tweede niveau van de Wet van Conway binnen Scrum, organiseren mensen zich rond bekwaamheidsgebieden waarin bekwaamheid waarde drijft. Deze “Birds of a Feather” helpen leden hun vaardigheid op een professioneel of technisch gebied te verdiepen terwijl ze ideeën uitwisselen of training volgen. De meeste mensen hebben een aangeboren verlangen om te verbeteren (zie ), en deze groepen voeden individuele trots terwijl teamleden leren en groeien. Maar nogmaals, deze groepen vormen geen rapportagestructuur, en elk teamlid kan tot meerdere “Birds of a Feather” behoren evenals tot zijn eigen Scrum Team. Zie ook Domeinexpertise in Rollen.

De grenzen en identiteit van het ontwikkelteam, evenals de grenzen en identiteit van het Scrum Team, zijn expliciet. De notie van teamidentiteit is de sleutel tot Team Trots en tot de efficiënte werking van de organisatie, omdat teamidentiteit de sociale context brengt die helpt de besluitvorming te optimaliseren. Elke notie van organisatorische identiteit buiten deze twee zou eerder stilzwijgend moeten zijn dan expliciet of beheerd. Nogmaals, er zijn geen formele titels binnen het Ontwikkelteam anders dan “Ontwikkelaar”. Als er slechts één onaantastbare regel is, dan is het dat geen enkel individu zijn stilzwijgende expertise kan gebruiken om een teamconsensus terzijde te schuiven of op enige andere wijze de geest van teamwork kan verminderen, zoals in The Spirit of the Game. Een gezamenlijk ontwikkelde Norms of Conduct is een sterke voorbode van teamidentiteit.

Er kan expertise in rollen zijn op individueel niveau, maar het is belangrijk om dit patroon waar mogelijk aan te vullen met Cross-Functionele Teams om de mogelijkheid van lokale besluitvorming te optimaliseren.

De oorspronkelijke Wet van Conway kwam uit de software (zie , pp. 28-31). Er zijn vele mythen verbonden aan de oorsprong en de praktijk van de Wet van Conway. Lange tijd werd beweerd dat object oriëntatie de Wet van Conway ondersteunde door het lokaliseren van de markt in de klassen. Dat is maar half waar; klassen hebben de neiging om de lange-termijn zorgen van organisatorische kerncompetentie in te kapselen. Toch lijkt object oriëntatie zich meer te richten op het verband tussen de expertise van ontwikkelaars en de artefacten die zij ontwikkelen dan op enig verband met de markt of met use cases. Bezorgdheid over afstemming op de marktstructuur zou moeten prevaleren boven bezorgdheid over het wereldbeeld van de ontwikkelaars over hun proces en product.

De waterval stijl van ontwikkelen heeft zijn hoogtijdagen gehad. In watervalorganisaties volgde de primaire organisatiestructuur de procesfasen: behoefteanalyse, ontwerp, implementatie en test (, pp. 1-9). Volgens de Wet van Conway weerspiegelde de organisatiestructuur deze procesoverwegingen. De software zou heel goed die fasen ook kunnen weerspiegelen: bijvoorbeeld, een Service-Oriented Architectuur (SOA) zal de meeste van de vereisten met toegevoegde waarde in de laag van de dienstintegratie bewijzen, terwijl de individuele diensten in een andere laag worden gevonden. Waterval legt alle functies in één keer in handen van de ontwikkelaars, wat het redeneren over interacties tussen functies ondersteunt. Terwijl de software ontwerpbenaderingen van het waterval tijdperk probeerden om marktzorgen (use cases) in lijn te brengen met de architectuur, doorbrak de organisatorische structuur die taxonomie. Hetzelfde kan worden gezegd over de lopende band organisatie in fabrieken.

Omdat ontwikkelteams feature teams zijn, zouden ze zich moeten concentreren op één feature tegelijk (zoals in Swarming). Scrum’s primaire deliverable voor de markt is een feature, en in die zin is er een goede afstemming tussen de teamstructuur en de markt. Scrum zwijgt over de vorm van de productarchitectuur, maar in de geest van agile neigt het ertoe individueel code-eigendom te ontmoedigen. Elk ontwikkelteam heeft een licentie om aan elk deel van het product te werken. Wij kunnen zeggen dat Scrum de organisatorische voordelen van inkapseling in evenwicht brengt met de voordelen van het op één lijn brengen van het team met het te leveren product. De Product Owner, met steun van het Development Team, beheert hoe om te gaan met feature interacties die in de loop van de tijd ontstaan.

Bedenk bijvoorbeeld dat het ene team de Call Waiting feature voor een telecom systeem implementeert terwijl een ander team Call Forwarding implementeert. Vanwege emergence, kunt u niet altijd voorzien in de kosten van het oplossen van afhankelijkheden tussen twee gegeven Product Backlog Items (PBI’s), dus het is, in het algemeen, onmogelijk om dit probleem te overwinnen door het toewijzen van PBI’s aan teams. In elk geval kan het voorbarig toewijzen van werk aan teams het onmogelijk maken voor mensen om effectief te werken aan de moeilijke delen (vooral die met betrekking tot de interactie tussen de delen) en beperkt het de zelforganisatie op het Scrum Team niveau. De twee onderdelen kunnen sterk van elkaar afhankelijk zijn, maar de Scrum structuur geeft geen eersteklas statuur aan die interacties. In dit geval zou het waarschijnlijk beter zijn als een enkel team beide functies zou ontwikkelen. Hoe je werk toewijst aan teams bouwt voort op voortdurende planning en gedeelde besluitvorming, te beginnen met Sprint Planning. Een goed Scrum Team streeft ernaar om het werk te verdelen over de ontwikkelteams door middel van intieme, maar in de tijd gebudgetteerde, interacties tussen de Product Owner en het ontwikkelteam, zoals in evenementen om voortdurend opnieuw een Verfijnde Product Backlog op te stellen, evenals door middel van Sprint Planning.

Management is meestal een onderdeel van de organisatorische mix, hoewel er Scrum ontwikkelingen zijn die draaien zonder managers (zie bijvoorbeeld de recente video over de agile transformatie bij Bosch Software Innovations. ) De Scrum ethos heeft de neiging zich te concentreren op de mensen en het product, en de focus wordt belichaamd in de Scrum rollen en de organisaties (zoals het Development Team en Product Owner Team) die ze vertegenwoordigen. Als een organisatie met reeds bestaande managers Scrum wil introduceren, is het te gemakkelijk voor de Scrum inspanning om het managementgedeelte van de organisatie af te doen als wereldvreemd. In dergelijke situaties waar een management-vrije organisatie geen optie is, is het cruciaal om de managers erbij te betrekken.

Steven Johnson. Where Good Ideas Come From. New York: Riverhead Trade, 2011.

Stewart Brand. Hoe gebouwen leren: What Happens After They’re Built. New York: Penguin, 1995.

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

Daniel Pink. Drive: De verbazingwekkende waarheid over wat ons motiveert. 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. (Oorspronkelijk gepubliceerd door TRW.)

Bosch Software Innovations. “Geleerde lessen: Agile organisatie bij Bosch Software Innovations.ˮ YouTube.com, 15 juni 2018, https://www.youtube.com/watch?v=CwodQs7D8BY.

Picture credits: Images Provided by PresenterMedia.com.