Waardestromen meten in softwarelevering met het Waardesysteemschema

Volledige tekst

1 Inleiding

Softwareteams worden nauwlettend gemeten: velocity, doorvoer, doorlooptijd, deployment-frequentie en het percentage mislukte wijzigingen worden automatisch verzameld. Toch laten deze cijfers één vraag open: welke waarde heeft het team geleverd, aan wie, en tegen welke kosten in verliezen?

Dit artikel stelt een methode voor om die vraag te beantwoorden met het Waardesysteemschema (Value System Schema, VSS), de modelleernotatie van de Æilus-methodologie, zoals geïmplementeerd in de VSS Editor die op aeilus.tech is gepubliceerd. Het is het vijfde artikel van de reeks "Æilus for Business". Het gebruikt de terminologie die in het eerste artikel van de reeks is gedefinieerd, "Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners" (Bolshakov, ÆVRI, 2026), en herhaalt die definities niet. De formele behandeling van waarde als meetbare valuta (Æ) wordt gegeven in "Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective" (Bolshakov, ÆVRI, 2026).

Het artikel beschrijft hoe een leverende organisatie een schema van haar waardesysteem kan opstellen, geplande en gerealiseerde waarde aan releases kan koppelen, stroomweerstand en lekkage kan lokaliseren, gedeelde technische knooppunten kan evalueren en de cyclus kan uitvoeren met duidelijke rollen en een vast ritme. Het steunt op de VMT-axioma's A1, A2, A4, A5, A6, A7, A11 en A13 en de stellingen T3, T4, T5, T6, T8, T9, T15, T16 en T17. Het bevat geen gemeten gegevens. Het uitgewerkte voorbeeld in paragraaf 9 is synthetisch.

2 Wat leveringsmetrieken meten en wat niet

Leveringsmetrieken beschrijven de beweging van werk. Velocity telt de afgeronde geschatte inspanning; doorvoer telt de afgeronde items. De vier kernmetrieken die door Forsgren, Humble und Kim (Accelerate, 2018) populair zijn gemaakt, namelijk deployment-frequentie, doorlooptijd van wijzigingen, hersteltijd van de dienst en percentage mislukte wijzigingen, beschrijven de snelheid en stabiliteit van de leveringspijplijn. Dat onderzoek verbindt deze capaciteiten met organisatieprestaties, en dit artikel betwist dat niet. De bewering ervan is smaller: deze metrieken beschrijven de pijplijn, niet de waarde die erdoorheen gaat.

Hieruit volgen drie hiaten.

• Inspanning is geen waarde. Een sprint met hoge velocity kan functies opleveren die niemand gebruikt. In de taal van de Product Value System deck: "features are not value" en "metrics are not value": een functie is een aanname over waarde, en een metriek is een interpretatie ervan.
• Snelheid is geen richting. Een korte doorlooptijd levert een verkeerde hypothese sneller af.
• Stabiliteit is niet de afwezigheid van anti-waarde. Een laag percentage mislukte wijzigingen zegt niets over vertraging, verwarring, herwerk aan de gebruikerskant of verlies van vertrouwen door een wijziging die precies zo werkte als ontworpen.

Vanuit het perspectief van de Value Management Theory (VMT) is het hiaat structureel. Waarde bestaat alleen binnen een gedefinieerd waardesysteem en wordt geïnterpreteerd door de actoren ervan (A1, A2). Zij wordt gerealiseerd op het moment van consumptie (A6), en geplande en gerealiseerde waarde verschillen doorgaans (A4, T3). Pijplijnmetrieken worden vóór de consumptie verzameld, aan de zijde van de afzender, en beschrijven dus hooguit de levering van geplande waarde. Wanneer zulke metrieken doelen worden, verschijnt het effect dat Goodhart (1975) beschreef: teams optimaliseren de teller. De VMT formuleert hetzelfde risico in systeemtermen: lokale optimalisatie garandeert geen globale verbetering (T5).

3 De notatie van het Waardesysteemschema

3.1 Elementen van de notatie

In de Æilus-methodologie is het Waardesysteemschema (Value System Schema) het eerste kernartefact: een formele beschrijving van het waardesysteem, zijn actoren, stromen, transformatoren en sleuteluitwisselingen, gebruikt om systeemgrenzen vast te stellen en onzichtbare externe afhankelijkheden te voorkomen. Een VSS kan worden getekend op het niveau van transformatoren of op systeemniveau.

De VSS Editor, in december 2025 uitgebracht op aeilus.tech, is een browsergebaseerde visuele editor voor dergelijke schema's. De notatie heeft een klein aantal elementen.

• Converters. Een converter (waardeconverter) is de Æilus-naam voor een transformatorrol in een schema: een functioneel blok, zoals een team, een dienst of een subsysteem, dat waide-elementen ontvangt, ze transformeert en nieuwe voortbrengt. Converters zijn de plaatsen waar waarde wordt gecreëerd, versterkt of vernietigd.
• Stromen. Een stroom is een gerichte verbinding tussen converters, of tussen een converter en de buitenwereld. Hij draagt een hoeveelheid waarde of anti-waarde in Æ. Een stroom is extern inkomend (waarde die het systeem binnenkomt), extern uitgaand (waarde die het systeem verlaat) of intern (waarde tussen converters).
• Invoer en uitvoer. Externe instromen en uitstromen markeren waar waarde binnenkomt en vertrekt. Samen bepalen zij de systeemgrens.
• Waide-elementen. Elementtypen beschrijven wat er precies door een stroom beweegt: klantwaarde, omzet, kosten, risico's, technische schuld en dergelijke. In een opgeslagen schema heeft elk element een soort (waarde of anti-waarde), een teken, een hoeveelheid en een eenheid (Æ).
• Anti-waarde. Anti-waarde vertegenwoordigt verliezen en negatieve effecten: vertraging, herwerk, defecten, bureaucratie, risico, burn-out, verspilde inspanning. In het schema is het een expliciet element met een negatief teken, niet de afwezigheid van waarde (A5).

3.2 Het schema als machineleesbaar model

De editor slaat een schema op als gestructureerde JSON met knooppunten (converters), stromen en elementen. Het schema kan daarom samen met het product worden geversioneerd en later worden gelezen door analyses die geplande en gerealiseerde hoeveelheden per stroom vergelijken. Dergelijke analyses zijn aangekondigd als toekomstig werk en worden hier niet verondersteld.

3.3 Wat het schema niet is

De VSS Editor is uitdrukkelijk geen KPI-dashboard, geen BI-tool, geen simulatie-engine en geen vervanging van de financiële boekhouding. Hij stelt duidelijkheid boven berekening. De aanbevolen modelleervolgorde luidt: definieer de grens, voeg alleen de belangrijkste converters toe, verbind ze met benoemde stromen (namen vóór getallen, richting vóór precisie), en markeer daarna anti-waarde, de stap die vaak de meeste inzichten oplevert.

4 Wiens waarde: het systeem en zijn grens

Een meting van waarde is zinloos zolang niet is vermeld wiens waarde wordt gemeten (A1, T1). De gekozen grens verandert bovendien de conclusies zonder enige verandering in de werkelijkheid (T15). Dit artikel legt het waardesysteem daarom vast vóór elke meting.

Het hier gemodelleerde waardesysteem is het productwaardesysteem van één softwareproduct binnen een productorganisatie. Volgens de Product Value System deck zijn de actoren de productfunctie, het ontwikkelteam, operations, het product in productie, de gebruikers en het bedrijf als ontvanger van de waarde die gebruikers teruggeven. Financiën is een externe faciliterende instroom (salarissen).

Twee gerealiseerde interpretaties worden gemeten: waarde voor gebruikers, geïnterpreteerd door gebruikers of hun waarneembare gedrag, en waarde voor het bedrijf, geïnterpreteerd door het bedrijf als ontvanger van de terugstroom (omzet, retentie, lagere kosten of risico). Geplande waarde is de interpretatie van de afzender vóór de release. De waarde van dezelfde release voor een partner of toezichthouder valt buiten de grens, tenzij die uitdrukkelijk wordt uitgebreid.

5 Van productehypothese tot gerealiseerde waarde: de waardelus

De Product Value System deck beschrijft productwerk als een lus waarin waardehypothesen worden gecreëerd, geïmplementeerd, gevalideerd en in stand gehouden. In schematermen heeft de lus de volgende converters en stromen.

1. Investering naar de productfunctie. De productfunctie zet middelen en gebruikerssignalen om in hypothesen met geplande waarde.
2. Productfunctie naar ontwikkeling. Hypothesen worden backlog-items met geplande waarde. De deck stelt twee verwachtingen: de geplande waarde van een hypothese mag niet afnemen terwijl zij wordt gebouwd, en de geleverde waarde mag niet veel afwijken van de geplande waarde.
3. Ontwikkeling naar operations. Ontwikkeling verbruikt inspanning en produceert werkende wijzigingen, samen met anti-waarde (technische schuld, defecten, vertraging).
4. Operations naar productie. Wijzigingen worden draaiende software; releasefouten en downtime verschijnen als anti-waarde.
5. Productie naar gebruikers. Waarde wordt alleen in gebruik gerealiseerd (A6), dus dit is het eerste punt waar gerealiseerde waarde kan worden waargenomen.
6. Gebruikers naar het bedrijf. Gebruikers geven omzet, retentie en vertrouwen terug. Het kanaalbericht van de auteur uit januari 2022 noemt dit een gesloten stroom: waarde die aan de klant wordt geleverd, wordt in evenwicht gebracht door waarde die terugvloeit, vaak maar niet alleen geld.

De lus maakt het transformatieaxioma concreet (A7): elke converter realiseert wat zij ontvangt en produceert nieuwe geplande waarde voor de volgende. Hij laat ook zien waarom pijplijnmetrieken alleen stap 3 en 4 bestrijken. Stap 1, 2, 5 en 6, waar waarde wordt gepland, gerealiseerd en teruggegeven, liggen buiten de pijplijn.

De deck vermeldt ook waarneembare elementtypen voor interne en externe producten. Waarde-elementen zijn onder meer bespaarde tijd, minder operationele fouten, cashflow, risicovermindering, lagere cognitieve belasting, voorspelbaarheid, nieuwe mogelijkheden en vertrouwen. Anti-waarde-tegenhangers zijn onder meer verloren tijd, herwerk, groeiende operationele kosten, technische schuld, onvoorspelbaarheid, handmatige omwegen, verlies van vertrouwen en verslechterde klantenservice. Deze typologie is het uitgangspunt van een Waarde-elementenregister voor oplevering.

6 Geplande en gerealiseerde waarde per release, weerstand en lekkage

6.1 De release als vergelijkingseenheid

De vergelijkingseenheid is de release, of het backlog-item wanneer releases klein zijn. Voor elk van deze legt de methode in Æ het volgende vast:

• geplande waarde: de schatting van de zender, vastgelegd voordat de ontwikkeling begint en alleen bijgewerkt via een expliciet, gelogd besluit;
• gerealiseerde waarde en gerealiseerde anti-waarde: de interpretatie van de ontvanger nadat de release gedurende een afgesproken observatieperiode in gebruik is geweest;
• retrospectieve waarde: een latere herwaardering, zodra tweede-ordegevolgen (supportbelasting, klantverloop, technische schuld) zichtbaar zijn geworden.

De deck stelt een gefaseerde invoering voor: eerst geplande waarde bij elk backlog-item, vervolgens gerealiseerde waarde en anti-waarde bij elk opgeleverd item, daarna retrospectieve waarde. Zonder geplande waarde is er geen verschil om te meten; zonder gerealiseerde waarde blijft het plan een hypothese.

6.2 Stroomweerstand in oplevering

Stroomweerstand (flow resistance) is het verschil tussen geplande en gerealiseerde waarde plus de anti-waarde die in een stroom ontstaat. VMT beschouwt een verschil ongelijk aan nul als normaal (T3), maar stelt dat weerstand zich historisch opstapelt (T4) en het vermogen om toekomstige waarde te realiseren vermindert (T6). Bij oplevering gaat waarde verloren in de implementatie (afgeslankte scope, verkeerd gelezen hypothese), in de release (defecten, rollbacks), in de adoptie (gebruikers kunnen de wijziging niet vinden of gebruiken) en door vertraging. In navolging van het concept van de kosten van vertraging (Reinertsen, 2009) wordt vertraging gemodelleerd als anti-waarde op de late stroom, niet als een afzonderlijke metriek.

Als elke stroom zijn eigen geplande en waargenomen grootheden draagt, laat het schema zien in welke converter het verlies is opgetreden. Dit is het doel van het Stroomweerstandsregister en het Rapport Gepland versus Gerealiseerd Waardeverschil in de artefactenset van Æilus.

6.3 Lekkage

Lekkage is een aanhoudend overschot van gerealiseerde waarde die het systeem verlaat ten opzichte van de waarde die het binnenkomt (A11). In een waardesysteem van een product komen twee vormen vaak voor. In de eerste hebben gebruikers voordeel, maar dekt de terugstroom de mogelijkmakende instroom niet. In de tweede verbruikt het team investeringen terwijl hypothesen worden opgebouwd maar nooit worden gerealiseerd. In beide gevallen kan de doorvoer gezond lijken; het schema toont beide, omdat instromen en uitstromen op één grens liggen.

7 Gedeelde knooppunten: evaluatie over alle stromen heen

Sommige converters in een softwaresysteem produceren geen waarde die een gebruiker zou noemen, maar elke waardestroom loopt erdoorheen. De kanaalpost van de auteur van september 2025 en het bijbehorende artikel op aeilus.tech gebruiken autorisatie als voorbeeld: het genereert zelf geen waarde, maar zonder autorisatie komt elk scenario tot stilstand. Een API-gateway of een CI-pipeline is van hetzelfde type.

Afzonderlijk geëvalueerd toont zo'n knooppunt kosten en geen opbrengst, en nodigt het uit tot kostenbesparing. In het schema verschijnt het op veel stromen tegelijk, en zijn efficiëntie wordt pas duidelijk via de totale waarde van alle stromen die het ondersteunt. De methode kent daarom aan een gedeeld knooppunt toe:

• de verzameling stromen die erdoorheen lopen, afgelezen uit het schema;
• de anti-waarde die het aan elk van die stromen toevoegt (latentie, storingen, mislukte logins, integratiedefecten);
• de verbruikte waarde (inspanning van het team, infrastructuur).

De efficiëntie ervan is de geleverde waarde minus de anti-waarde over al zijn stromen, afgezet tegen de verbruikte waarde, in navolging van de definitie van procesefficiëntie uit hetzelfde artikel. Een verslechtering in een gedeeld knooppunt is nooit een lokaal incident; het is weerstand die wordt toegevoegd aan elke stroom die het bedient. Stelling T8 voegt een duurzaamheidsargument toe: stabiliteit gaat verloren wanneer een transformatierol niet kan worden vervuld, en redundantie van de rol vergroot de stabiliteit.

8 Wat een teamleider wint

De kanaalpost van de auteur van februari 2022 somt op wat de aanpak een team en zijn leider oplevert. Herformuleerd in de termen van dit artikel:

• Geleverde waarde als feedback. Voor elke periode ziet het team de waarde die het heeft geleverd, in Æ, bevestigd door ontvangers, in plaats van het indirecte signaal van velocity.
• Een effectiviteitsmaat die los staat van de procesmethodologie. Welke praktijk ook wordt gevolgd, de maat is gerealiseerde waarde per verbruikte waarde, en praktijken worden gekozen of afgeschaft op basis van hun effect daarop (P7).
• Transparantie voor het bedrijf. Technisch werk wordt uitlegbaar via de stromen die het ondersteunt.
• Backlog-prioriteit op basis van waarde. Prioriteit kan worden afgeleid van geplande waarde, het vertrouwen daarin en de kosten van vertraging, in plaats van van de luidste stakeholder.
• Kosten van vertraging en productiefouten als anti-waarde. Het bedrijf kan laten zien hoe waarde daalt wanneer een wijziging te laat of foutief is, en het team ziet hoe het nut van zijn werk afhangt van timing en productiekwaliteit.
• Argumenten voor gedeelde middelen. Waar beheerders en DevOps-engineers worden gedeeld, verklaart op waarde gebaseerde prioriteit waarom het werk van het ene team werd uitgesteld ten gunste van dat van een ander, in beide richtingen.

Deze voordelen gelden alleen als gerealiseerde waarde door de ontvangers wordt gevalideerd. Als het team zijn eigen waarde schat en bevestigt, wordt de maat een zoveelste zelfgerapporteerde teller, en is T17 van toepassing: interpretaties van invloedrijke bronnen die niet door realisatie worden bevestigd, stapelen anti-waarde op.

9 Een uitgewerkt schema van een synthetisch product

Deze sectie beschrijft een synthetisch, illustratief product. Het is geen casestudy, het beschrijft geen enkele echte organisatie en het bevat geen gemeten cijfers.

Het synthetische product is een webapplicatie op abonnementsbasis waarmee kleine dienstverlenende bedrijven boekingen van klanten accepteren. Het waardesysteem volgt de grens die in Sectie 4 is gedefinieerd. Twee gedeelde knooppunten, een autorisatieservice en een API-gateway, bedienen alle gebruikersgerichte stromen. Financiën levert de mogelijkmakende instroom. Het bedrijf ontvangt abonnementsinkomsten en klantbehoud als terugstroom.

Het schema wordt in de VSS Editor opgebouwd in vier rondes: de grens met één externe instroom (investering en salarissen) en de externe uitstromen naar gebruikers; zeven converters; stromen die zijn benoemd naar de waarde-elementen die ze dragen; en anti-waarde-elementen. Grootheden blijven leeg tot de eerste schattingssessie.

Neem één hypothetische release: een herinneringsfunctie die bedoeld is om gemiste afspraken te verminderen. Vóór de ontwikkeling legt de product owner de geplande waarde per element vast (bespaarde tijd, minder gemiste boekingen, verwacht effect op retentie). Na een afgesproken observatieperiode leveren productanalyse en een steekproef van zakelijke gebruikers de gerealiseerde waarde, en legt het team de gerealiseerde anti-waarde vast: een late release, een defect dat dubbele herinneringen verstuurde, extra belasting op de API-gateway. Het verschil is de stroomweerstand van deze release. Het defect en de belasting van de gateway bevinden zich ook op stromen die andere scenario's bedienen, en worden daarom ook aan de gedeelde knooppunten toegewezen. Een kwartaal later laat de retrospectieve waarde zien of de retentie überhaupt is veranderd. In een echte toepassing zouden de hoeveelheden voortkomen uit de sessies die hierna worden beschreven.

10 Hoe het uit te voeren

10.1 Wie schat en wie valideert

De Æilus-regel uit de post van 2025 is kort: de outputwaarde van een proces moet worden beoordeeld door degene die haar consumeert, en iemand anders moet die beoordeling controleren. Toegepast op delivery levert dit een duidelijke taakverdeling op.

• Geplande waarde wordt geschat door de zender. Bij hypothesen is dit de product owner, die optreedt als Eigenaar Waardetransformator (Value Transformer Owner, VTO) van de producttransformator. Bij de ontwikkeltransformator is dit de teamleider als VTO.
• Gerealiseerde waarde wordt geïnterpreteerd door de ontvanger: gebruikers, waargenomen via product- of webanalyse, en het bedrijf voor de terugkerende stroom. De presentatie stelt als tijdelijke maatregel voor dat productanalyse de gebruikerskant vertegenwoordigt totdat directe validatie is ingericht.
• Validatie van de interpretatie wordt gedaan door een tweede partij: de Eigenaar Waardesysteem (Value System Owner, VSO), die verantwoordelijk is voor duurzaamheid op systeemniveau, of een Stroomeigenaar voor een kritieke stroom.
• Methodologische integriteit wordt ondersteund door een Æilus Master (in de presentatie een Æilus-champion die door een projectmanager wordt vervuld), die de rapporten over waardelevering, plan versus feit en stroomweerstand opstelt.

10.2 Cadans

Æilus schrijft geen kalender voor. Een minimale cadans voor een deliveryteam, in overeenstemming met de door de methodologie aanbevolen gebeurtenissen, is de volgende.

• Per backlogrefinement: aan nieuwe items wordt geplande waarde toegewezen, met behulp van het elementenregister.
• Per release, na de observatieperiode: gerealiseerde waarde en anti-waarde worden vastgelegd en gevalideerd; een kort waarderetrospectief bespreekt het verschil.
• Maandelijks of per kwartaal: een Stroomweerstandsreview over het schema, inclusief gedeelde knooppunten; retrospectieve waarde voor eerder opgeleverde items.
• Per kwartaal of bij structurele verandering: een Waardesysteemreview van grenzen, transformatoren en afhankelijkheden, waarbij het schemabestand wordt bijgewerkt en van versies wordt voorzien.

10.3 Discipline

Elk artefact heeft een eigenaar, een updatecyclus en een beslisdoel nodig; anders creëert het anti-waarde door onderhoudskosten en schijnzekerheid. Voor deze methode zijn de beslisdoelen backlogprioriteit, toewijzing van gedeelde middelen, timing van releases en investeringen in gedeelde knooppunten. Groei van geplande waarde is alleen toelaatbaar wanneer het vermogen van het team om die te realiseren is bevestigd (P9). Geplande waarde sneller opschalen dan gerealiseerde waarde is de faalwijze die door T16 wordt beschreven.

11 Beperkingen en wat een empirisch onderzoek nodig zou hebben

Dit artikel is conceptueel en is niet getoetst aan gemeten data. Er volgen enkele beperkingen.

• Kwaliteit van schattingen. Waarden in Æ zijn interpretaties waarvan de betrouwbaarheid afhangt van de schatters en hun kalibratie.
• Gedeeltelijke vergelijkbaarheid. Bespaarde tijd, omzet en vertrouwen zijn slechts gedeeltelijk vergelijkbaar (A13). Om ze in één munteenheid uit te drukken is een Waarde-aggregatiebeleid nodig, dat dit artikel veronderstelt maar niet definieert.
• Toerekening. Gerealiseerde waarde is vaak het resultaat van meerdere releases en externe factoren; het schema toont structuur, maar kan de bijdrage van één release niet isoleren.
• Verborgen stromen. Als het schema de waargenomen stabiliteit of achteruitgang van het systeem niet kan verklaren, zijn er latente stromen of klopt de grens niet (T9). Een schema is een hypothese over structuur en moet worden herzien.
• Kosten van de methode. Sessies die geen beslissingen opleveren, maken de methode zelf tot anti-waarde.

Een empirisch onderzoek zou minimaal het volgende nodig hebben: meerdere deliveryteams die de methode lang genoeg toepassen om retrospectieve waarde vast te leggen; een stabiel elementenregister en aggregatiebeleid dat vóór de gegevensverzameling is afgesproken; onafhankelijke validatie van gerealiseerde waarde door ontvangers in plaats van door de teams; parallelle verzameling van conventionele deliverymetrieken, zodat de relatie tussen die metrieken en gerealiseerde waarde kan worden onderzocht; en een vergelijking van beslissingen die met en zonder het schema zijn genomen. Alleen zo'n onderzoek kan aantonen of op waarde gebaseerde prioritering de geleverde waarde verandert, en onder welke voorwaarden.

12 Conclusie

Deliverymetrieken beschrijven hoe werk door een pijplijn beweegt, niet wat het voor de ontvangers heeft veranderd; onder VMT kunnen ze dat ook niet, omdat waarde contextueel is, pas in gebruik wordt gerealiseerd, en geplande en gerealiseerde waarde uiteenlopen. Het Waardesysteemschema (Value System Schema), zoals geïmplementeerd in de VSS Editor, stelt softwareteams in staat de waardelus van het product te tekenen, van hypothese tot gerealiseerde waarde en terug naar het bedrijf. Het vastleggen van geplande, gerealiseerde en retrospectieve waarde per release maakt van de lus een meting: stroomweerstand en lekkage worden zichtbaar, gedeelde knooppunten worden beoordeeld over elke stroom die zij bedienen, en teamleiders krijgen geleverde waarde, op waarde gebaseerde prioriteit en de kosten van vertraging en fouten als feedback. De methode blijft alleen eerlijk als de systeemgrens wordt benoemd, ontvangers de gerealiseerde waarde valideren en elk artefact een beslissing dient. Of zij in de praktijk de geleverde waarde verbetert, is een empirische vraag die dit artikel formuleert maar niet beantwoordt.

Referenties

• Bolshakov, V. Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective. ÆVRI, 2026.
• Bolshakov, V. Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners. ÆVRI, 2026.
• Bolshakov, V. Value Management Theory (VMT), version 1.4. 2026.
• Bolshakov, V. Value Management Methodology Æilus, v2.0. 2026.
• Bolshakov, V. VMT, Æilus v2.0 and the Product Value System (presentation). 2026.
• Bolshakov, V. New Tool Released: Value System Schema Editor (VSS Editor). aeilus.tech, 2025.
• Bolshakov, V. Assessing the Value of Processes: Efficiency, Risks, and Anti-Value. aeilus.tech, 2025.
• Bolshakov, V. Artifacts and Reports. Æilus methodology, aeilus.tech/methodology/artifacts-and-reports/. 2026.
• Bolshakov, V. Æilus channel posts on value flows, team leadership and the VSS Editor (in het Russisch). 2022-2025.
• Forsgren, N., Humble, J., Kim, G. Accelerate: The Science of Lean Software and DevOps. 2018.
• Goodhart, C. Problems of Monetary Management: The U.K. Experience. 1975.
• Reinertsen, D. The Principles of Product Development Flow. 2009.