Wet van conway

…in middelgrote tot grote organisaties tekent een beginnende systeemarchitectuur zich af. Diverse ontwikkelteams ontstaan. De eerste sprints leveren werkende systemen op.

✣  ✣  ✣

De nieuwe organisatie en het nieuwe systeem versterken elkaar wederzijds zodat er zowel effectief als efficient gewerkt kan worden.

De wet van conway is een van computerprogrammeur Melvin Conway die het idee in 1986 introduceerde:

Organisaties die systemen ontwerpen zijn beperkt tot het produceren van ontwerpen die kopieën zijn van de communicatiestructuren van die organisaties.

De wet van conway is een valide sociologische observatie. Om bijvoorbeeld twee separate softwaremodules correct op elkaar te laten aansluiten moeten de ontwerpers en bouwers met elkaar communiceren. Daarom zal de structuur van deze aansluitingen in het systeem de sociale structuren van haar ontwerpers en bouwers spiegelen.

Mel Conway observeerde dat er een zeer nauw verband is tussen de structuur van een systeem en de structuur van de organisatie die het ontwierp.

…Elke organisatie die een systeem ontwerpt zal onvermijdelijk een ontwerp produceren waarvan de structuur een kopie is van de communicatiestructuur van de organisatie.

Anders geformuleerd:

…Merk op hoe de bestaande organisationele structuur veranderingen in architecturele structuur verhindert.

De bestaande structuur (= architectuur = ordening) van een organisatie is mogelijk het grootste en moeilijkst te slechten knelpunt voor de hervorming naar een organisatie met personateams die zich om de behoeften van haar klanten heenvouwen.

Daarom:

Verzeker je ervan dat de organisatiestructuur en de systeemarchitectuur elkaar weerspiegelen en uitwisselbaar zijn met elkaar. Ontwerp nieuwe sociale en organisatorische structuren die het bereiken van het doel katalyseren. Koester een gemeenschappelijke woordenschat, met name voor systeemontwerp en -architectuur, die aansluit bij het grootse gevaarlijke gedurfde doel (en anders is dan de bestaande).

✣  ✣  ✣

✣  ✣  ✣

Conway's observatie vertelt hoe team- en organisatiestructuur ontwerp (ver)hindert en moet zeker niet als aanbeveling worden geïnterpreteerd.

Het (software)product spiegelt de structuur van de organisatie die haar bouwt. Als je een grote, slome organisatie hebt, neig je naar het bouwen van grote, slome software.

De mate waarin een organisatie niet volledig flexibel is in haar communicatiestructuur bepaalt in welk mate ze in elk ontwerp een spiegelbeeld van zichzelf stempelt. Omdat het ontwerp dat het eerst verschijnt bijna nooit de best mogelijk is moet het overheersende systeemconcept mogelijk wijzigen. Daarom is de flexibiliteit van een organisatie belangrijk voor effectief ontwerp. Koester en eer daarom die organisatie-ontwerpers die de organisatie lenig, wendbaar en flexibel houden.

Gedachte-experiment met twee opties: Iedereen die aan het product werkt:

1. kan één en slechts één kleine taak extreem goed uitvoeren, maar geen enkele andere.
2. kan alle activiteiten goed uitvoeren en blinkt uit in een enkele.

Welke optie maakt meer doorvoer van producteigenschappen toen? Welke optie heeft meer flessenhalzen? Welke biedt meer aanpasbaarheid en flexibiliteit? Ook al is de eerste optie niet of nauwelijks haalbaar, op een continuüm van wenselijkheid willen we een lerende organisatie aanmoedigen die in die richting beweegt—flessenhalzen verminderend, mensen die één gebied goed kennen, dan twee, …

Observaties:

• Ontwikkelen van mulit-vaardige mensen creëert rijkelijke leerkansen en nauwe samenwerking met verschillende soorten experts.
• Ontwikkelen van programmeurs die bij verschillende componenten kinnen helpen vereist een variëteit van ervaringen en mentoren.
• Gegevens tonen een buitengewone variantie in individuele productiviteit van programmeurs—onderzoeken suggereren een gemiddelde van vier keer sneller in de top versus de bodem kwartiel.

Er is een sterk verband in software-ontwikkeling tussen wat je weet en wat je goed kan doen'—software is het perfecte voorbeeld van een kennis-intensief beroep. Kortom, er zijn grote zakelijke voordelen als we vaardige ontwikkelaars hebben die voortdurend leren.

Dit leren kent een aantal eerste voorwaarden voor verantwoordelijkheden voor de leiding:

• ruimte voor reflectie—praktijk van veel code schrijven, code lezen van anderen en reflecteren op beide; en
• een structuur die voortdurend leren ondersteund.

Je kunt als organisatie willen versnellen, maar als je niet ook van richting kunt veranderen ga je steeds harder op je ondergang af. Nog een wrak op de weg.

De hoeveelheid vertraging, organisatie van de organisatie, overtollig management, overdrachten, slechte code, duplicering, en complexiteit van coördinatie die wordt geïntroduceerd in grote groepen die zich in componentteams organiseren wordt in de eerste plaats gedreven door twee angsten:

1. mensen kunnen of behoren geen nieuwe vaardigheden te leren (andere componenten, testen, …); en
2. code kan niet effectief gedeeld en geïntegreerd worden tussen mensen.

De eerste aanname is gelukkig onwaar en de tweede, meer waar in de zeventiger jaren, is ondertussen opgelost met wendbare bouwparktijken (agile engineering practices) zoals testgedreven ontwikkeling (test-driven development of TDD), doorlopende integratie (continuous integration) en doorlopende ingebruikname (continuous deployment).

In de zeventiger jaren leken componentteams een logische structuur vanwege haar seriële ontwikkelcyclus, breekbare versiebeheer, zwakke testinstrumenten en praktijken omdat schijnbare voordelen waren:

• Mensen ontwikkelen smalle gespecialiseerde vaardigheden die tot schijnbaar sneller werken leiden als je ze lokaal in plaats van op de gehele systeemdoorvoer van gegenereerde klantwaarde en op korte in plaats van lange termijn bekijkt;
• die specialisten breken hun code minder waarschijnlijk; en
• er zijn geen conflicterende veranderingen in de code door andere teams.

Gelukkig zijn er ondertussen nieuwe structuren voor levenscycli en teams ontdekt en zijn er krachtige, nieuwe en robuuste praktijken en instrumenten voor versiebeheer, integratie en testen.

• Producteigenschappen beelden zich gebruikelijk niet één-op-één af op componenten en daarom ook niet op een componentteam. Meestal overspannen producteigenschappen meerdere componenten en modules. Het kost tijd en geld en managers om de onderlinge afhankelijkheden te coördineren en op elkaar af te stemmen.
• Als meerdere componententeams betrokken zijn is het onduidelijk wie er eindverantwoordelijk is voor analyse van eisen. Dit leidt tot een afzonderlijke analist of analistenteam.
• Een aparte requirements architect dient op hoog niveau het systeem met haar componenten en modules te ontwerpen en te ontleden naar componententeams. Vaak leidt dat tot een matrixtabel die componenten en eigenschappen met elkaar in verband brengt. Ook die tabel moet weer onderhouden worden.
• Van begin tot eind testen van een produceigenschap hoort niet bij een specifiek componentteam thuis. De verantwoordelijkheid hiervoor beleggen kost veel moeite en coördinatie. Een apart systeemtestteam die pas starten met testen nadat de ontwikkeling klaar is—vaak veel later omdat ze het werk van álle verschillende componentteams nodig hebben en deze zelden op het zelfde moment klaar zijn. Bovendien hebben ze een aanzienlijke werkvoorraad van alle andere producteigenschappen die ze moeten testen.

Over ontleden gesproken:

• samenstellende delen af te zonderen;
• op te lossen in de originele elementen;
• vrijstellen van eerder bestaande vormen van (chemische) combinatie;
• tot ontbinding te brengen;
• te laten rotten of bederven.

En dat terwijl we er juist een geheel van willen maken.

Waterval ten voeten uit. Enorme verkwisting in overdrachten, goedkeuringen, overleggen, coördinatie, vertraging en voorraden met een houdbaarheidsdatum. Typisch sequentieel ontwikkelen, levenscyclus en mentaliteit. Vreemd genoeg hebben mensen de illusie dat ze agile of scrum ‘doen’ omdat ze miniwatervallen in een kortere en iteratieve cyclus doen. Maar miniwatervallen zijn niet lean en agile ontwikkelen. We willen liever gelijktijdig ingenieurswerk.

Het afmaken van een enkele, niet-triviale producteigenschap kost nu typisch vijf of zes iteraties in plaats van een—en dat is zelfs een optimistische inschatting. Erger nog, voor zeer grote systemen voegt de organisatie een vet platform toe, inclusief haar architect en test—elk gespecialiseerd en elk een fasevertraging toevoegend voordat we eindelijk toegevoegde waarde aan de klant kunnen leveren.

Structuren van componentteams en de ontwikkelingen van de sequentiële levenscyclus gaan hand in hand.

Er zit een systemisch gebrek in componentteams.

In traditionele productgroepen voor grote producten met componentteams weten de meeste ontwikkelaars slechts een smal fragment van het systeem, en meest in het oog springend is dat ze weinig zaken zien of leren die nieuw zijn. En dat terwijl de meeste mensen toch vooral plezier scheppen in nieuwe dingen doen.

Tegelijkertijd zijn er altijd enkele wonderbaarlijke mensen die heel veel over het systeem weten—die mensen waar je naar toe gaat als er een onverklaarbare fout optreedt. Als je vraagt hoe dat mogelijk is, krijg je vaak het antwoord, “Hij weet alles omdat hij altijd ieders code leest.”. Of, “Hij heeft aan veel verschillende code gewerkt.”. Interessant genoeg kom je meer van dit soort mensen tegen bij grote succesvolle open bron producten.Er is culturele waarde in “Gebruik de bron, Luuk” die het lezen en delen van kennis via code bevordert.

Wat doet dit er toe? Componentteams verhinderen ontwikkelaars het lezen en leren van nieuwe gebieden van de codebasis, en, breder, van het leren van nieuwe dingen.

Contrasteer deze organisationele mentaliteit met die van Peter Senge's Het Vijfde Discipline waarin hij de cultuur, focus en geest van langlevende bedrijven samenvat: lerende organisaties. Lean Process and Product Development benadrukt dit thema ook en vat de inzichten van het succes van Toyota's nieuwe productontwikkeling samen: Het gaat over het creëren van bakken kennis en over voortdurend leren.

Bij Toyota zeggen ze:

“Mono zukuri wa hito zukuri”

“Dingen maken gaat over mensen maken.”

Componententeams verhinderen een lerende organisatie waarin ontwikkelaars uiteindelijk vaardig wordt in een gebied, en dan in nog een, en nog een. Zo bouwt ze een leerschuld op.

---