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. Leren dat had moeten gebeuren maar niet is gedaan vanwege enge gerichte specialisten, korte termijn oplossingen, brandbestrijding, gebrek aan reflectie en achterblijven met moderne ontwikkelingen. Wie niet met zijn tijd meegaat, gaat mettertijd. In het begin, bij een jong product, merk je nog niet zoveel van die schuld, maar naar mate het product ouder wordt, wordt het zwaarder en zwaarder.

Componentteams maken lui en sporen makkelijker werken aan, niet het leveren van meer waarde. Componentspecialisten creëren, net zoals als andere enkelvoudige specialisten, een organisationele dwang of flessenhals. Dit leidt tot een fascinerende suboptimalisatie: Werk wordt vaak gekozen op basis van specialisme dan klantwaarde. Vaak worden die producteigenschappen gekozen die de specialisten het best en snelst kunnen realiseren. Hierdoor neigt er een maximale hoeveelheid code gegenereerd te worden, ten koste van waardecreatie voor de klant. Code die door slechts enkele begrepen en onderhouden kan worden en toevoegd aan de technische schuld. Componentteams kiezen dus als vanzelf voor de makkelijkste zaken en niet voor de meest waardevolle. Soms kiezen componentteams voor de realisatie van zaken die pas over een half jaar nodig zijn en genereren daarmee potentieel afval (waste).

Vaak is deze suboptimalisatie en creatie van afval onzichtbaar, omdat:

1. er geen prioritering op basis van klantwaarde is, of de prioritering vindt plaats op basis bizarre en grofkorrelige zaken zoals “verplicht” en “absoluut verplicht”;
2. componentteams zijn druk bezig de fouten van hun component te herstellen; en
3. er is ruim voldoende werk voor interne lokale verbeteringen.

Iedereen lijkt uitermate druk—ze moeten wel waardevol werk doen!

Deze sub-optimalisatie wordt duidelijk zodra je een echte product werkvoorraad maakt die geprioriteerd is op basis van waarde voor de klant.

Poel met Hulpbronnen

Een snelle oplossing om het prioriteitsprobleem op te lossen is door projecten de creëren waarop specialisten worden ingezet. Projectmanagers kiezen mensen uit een poel van specialisten en geven ze terug aan de poel zodra het project is afgelopen. Hierdoor ontstaan projectgroepen of producteigenschapprojecten met matrixmanagement. In dergelijke organisaties worden mensen gedegradeerd tot ‘hulpbron’, alsof het machineonderdelen zijn en menselijke en teamdynamiek niet van belang zijn voor productiviteit of motivatie.

Met een poel van hulpbronnen vouwt het management de organisatie rondom enkelvoudige specialisten. Op papier of in een projectmanagementistrument ziet dat er misschien goed uit, maar in werkelijkheid blijkt dat mensen geen machines zijn—ze kunnen leren, geïnspireerd of gedemotiveerd raken, focus krijgen of verliezen, etc. In praktijk heeft een poel met hulpbronnen vele nadelen:

• Lagere productiviteit door losse projectgroepen—kortlevende groepen mensen die samengebracht worden voor een project—een “projectgroep”—hebben een aantoonbaar lagere productiviteit.
• Lagere motivatie en werkplezier—“Wij haten het om in een poel van hulpbronnen te zitten en in meerdere kortlevende projectgroepen gegooid te worden.” is een veelgehoorde klacht.
• Minder lering—Enkelvoudige specialisten werken en leren zelden buiten hun gebied.
• Lagere productiviteit door multi-tasking—Meestal worden de beschikbare specialisten dun uitgesmeerd over verschillende projecten, 20% op project A, 40% op project B, 10% project C, enzovoort. Hierdoor wordt de specialist gedwongen tot multi-tasking en kostbare contextwisselingen hetgeen ten koste gaat van productiviteit en motivatie.
• Lagere productiviteit en doorvoer vanwege toegenomen overdracht en verkwisting door wachten—

---