blog-header SAFe deel 2

In dit tweede deel van mijn serie blogs over SAFe (Scaled Agile Framework) 4.0 bespreek ik een voor mij ondergeschoven kindje in agile: ‘Solution intent’.

Wat is ‘Solution intent’?

‘Solution intent’ is de kennisbank waarin alle eisen, oplossingen en voorgenomen doelen voor het te ontwikkelen product worden verzameld en onderhouden. Deze kennisbank kan vele vormen hebben afhankelijk van de situatie waarbinnen een product wordt gebruikt.

SAFe principe nummer 3 zegt: ‘Assume variability; preserve options’. Dit betekent min of meer ‘Ga uit van een variabele set aan eisen, een variabele omvang van die eisen, en houd meerdere opties open voor de oplossing ervan tot het laatste, te verantwoorden moment’.

Stokpaardjes

Twee van mijn stokpaardjes worden door deze toevoeging aan SAFe geadresseerd:

  • De paradigmaverschuiving ‘van denken in oplossingen, naar denken in eisen’;
  • De te grote focus op tijdelijke (vergankelijke) documentatie ten opzichte van permanente documentatie en het structurele gebrek aan goed eisenmanagement vanuit het verleden.

Ik licht ze toe.

De paradigmaverschuiving ‘van denken in oplossingen, naar denken in eisen’

solution-intent

Het eerste stokpaardje wordt mooi weergegeven door het onderscheid tussen ‘Variable and ‘Fixed Solution intent’. Als je op de site www.scaledagileframework.com klikt op het ‘Solution intent’ icoon (midden links in de uitgeklapte value stream laag), zie je figuur 5 ‘Moving from variable to fixed solution intent’. Dit visualiseert heel mooi hoe eisen evolueren in de tijd, en hoe de oplossing mee evolueert, totdat eisen en oplossing uiteindelijk vast staan, ‘fixed’ zijn.

In deel 1 van deze blogserie heb ik voorbeelden gegeven van de hiërarchie aan eisen (puur op omvang van die eisen) die mogelijk is, middels het Tesla voorbeeld. Dit illustreert letterlijk dat je, totdat een ‘User Story’ in een sprint wordt getrokken, op het allerlaatste niveau nog steeds in klant eisen denkt (‘bij voorkeur’, want dit is in de praktijk niet altijd mogelijk). Een klanteis is een wens die is uitgedrukt in Business termen die iedereen kan begrijpen en lezen. Naarmate deze eisen worden opgesplitst in kleinere eisen, zal ook de oplossing verder worden uitgekristalliseerd. Bij een Epic kan het alleen nog gaan over mogelijke oplossingsrichtingen voor het geheel, en architecturele kaders. Bij een capability om een reeds gekozen oplossingsrichting. Bij een Feature om een globale invulling van de oplossingsrichting voor die specifieke feature. Ditzelfde geldt ook voor een Story. Maar het volledige ontwerp (als dat wordt bijgehouden in welke vorm dan ook), wordt pas geüpdatet in de sprint zelf. Per User Story wordt ontwerp, bouw en test doorlopen volgens het ‘King principe’ van Henrik Kniberg.

De ‘Rolling wave’ van de creatie en detaillering van de (delta)eisen zorgt ervoor dat eisen constant verder worden uitgewerkt en dat oplossingen voor die eisen mee evolueren. Alle wachtrij-principes van Reinertsen dragen hiertoe bij. De volgende tekening van ‘Flow’ maak ik altijd in mijn training. Deze verduidelijkt hoe de eisen (als je drie lagen van wachtrijen met eigen typen eisen hanteert) evolueren in die wachtrijen:

Figuur 1. De flow van eisen in SAFe

Figuur 1. De flow van eisen in SAFe

Ik kom nog veel te veel situaties tegen waar geen eisen maar oplossingen in de backlog items zijn verwoord. Of dat er veel te veel backlog items al gedetailleerd zijn. Het (minimum, analoog ‘little’s law’) aantal gedetailleerde items in de backlog staat altijd op gespannen voet met de hoeveelheid gedetailleerde items die noodzakelijk zijn om een efficiënte planning event te voeden. Naar deze balans moet een team, of team van teams, altijd blijven zoeken.

De flow van eisen die ik hier beschrijf, bestaat in het geheel uit tijdelijke documentatie die slechts een delta beschrijft van de toekomstige werking van een product of proces. En hier komen we aan stokpaardje nummer 2.

De te grote focus op tijdelijke (vergankelijke) documentatie ten opzichte van permanente documentatie en het structurele gebrek aan goed eisen management vanuit het verleden.

Zoals gezegd, de flow van Epics, features en User Stories is een flow met delta eisen (Future requirements). Deze delta’s op de baseline aan eisen (Current requirements), op basis waarvan de huidige werking van een product of business process is gestoeld, zijn slechts van tijdelijke aard. Na een project of release, of na implementatie van de story, kunnen ze weg. Natuurlijk bieden tools tegenwoordig de mogelijkheid om de historie te bewaren. Maar ga maar eens impact analyse doen op een systeem waarvan de actuele baseline aan eisen NIET is vastgelegd. Dan moet je de hele historie van delta beschrijvingen door gaan spitten?! Zeer arbeidsintensief.

In figuur 1. ‘Anatomy of Solution intent’ in het Solution intent abstract van de SAFe site, zie je duidelijk het verschil aangegeven tussen ‘future’ en ‘current’ requirements en designs.

Vrijwel overal waar ik kom is een gebrek aan actuele permanente baseline voor wat betreft eisendocumentatie. Ik zie met de hele agile beweging zelfs nog een versterking van de focus op tijdelijke documentatie (als Epics, features en stories), ten opzichte van goede baseline domeindocumentatie. Maar dit is niet nieuw. Ook in watervalsituaties kom ik tegen dat detailontwerpdocumentatie helemaal in een wijzigingsvoorstel (delta) komt te staan en dat de domeindocumentatie nooit meer wordt geactualiseerd!

Als ik vraag hebben jullie een baseline aan eisendocumentatie, is het antwoord meestal al nee, we hebben alleen ontwerp documentatie (we kunnen alleen maar in oplossingen denken in de IT). En als ik vraag wat is de status / kwaliteit van de ontwerpdocumentatie, dan is het antwoord nog te vaak: ‘Die is niet actueel’. Op mijn vraag waarop wordt dan impact analyse gedaan, krijg ik dan als antwoord: ‘De code’. Dit is zeer triest.

Hoe komt dit? Volgens mij is het een combinatie van vele factoren:

  • Gebrek aan discipline;
  • Management die hun eigen primaire (IT lifecycle) proces niet kent, waardoor;
  • Geen investeringsbereidheid van management en project management in tijd voor eisenmanagement en kosten voor eisenmanagementtooling;
  • Beginnen met ontwerp, en eisen laten liggen;
  • De figuurlijke ‘zweep’ op het team om een einddatum te halen;
  • Gebrek aan eigenaarschap van een product (als een tijdelijk innovatieteam wordt ontbonden kan het ze niet meer schelen als beheer veel patchwork krijgt);
  • De vicieuze cirkel van: Geen actuele eisen documentatie > veel tijd benodigd voor impact analyse > te weinig tijd voor actualiseren of opzetten eisendocumentatie;
  • Inhuur van leveranciers die documentatiestandaard niet kennen.
  • Etc.

Voor vastlegging en traceerbaarheid van dit geheel is de genoemde kennisbank nodig. En of dit nu in zeer kleine organisaties met producten die tijdelijk zijn of processen die weinig bedrijfskritisch zijn op een whiteboard of in excel gedaan word, of dat we het hebben over bedrijfskritische systemen in grote complexe IT-landschappen, waar we requirements management tooling gebruiken. Vastlegging is noodzakelijk. Voor redenen als: audit trail, accountancy, traceability, gedistribueerd werken, fast impact analysis, metrics. Om dit te visualiseren heb ik de eerdere figuur uitgebreid:

Aanpassen (actualiseren) van de permanente eisen documentatie

Figuur 2. Aanpassen (actualiseren) van de permanente eisendocumentatie op momenten dat een delta-eis wordt ge-pulled.

MBSE

‘Model Based System Engineering heeft ook een plaats gekregen in 4.0. Leffingwell zegt: ‘Als je dan domeindocumentatie maakt, maak dan visuele documentatie’. Visuele documentatie is veel makkelijker te begrijpen en aan te passen, en vooral, te communiceren. Dit is de reden dat ik bij de permanente documentatie in figuur 2 drie modellen uit UML heb genoemd: ‘Domain Model’, ‘Business Use Case Model’ en ‘System Use Case Model’.

Epiloog

En hoe verhoudt zich alles wat ik hier heb beschreven nu ten opzichte van de agile principes?

Wat te denken van: ‘We value working software over comprehensive documentation’.

En: ‘Simplicity — the art of maximizing the amount of work not done — is essential’

Het eerste principe wordt veel te veel verkeerd geïnterpreteerd. Alsof we nooit meer hoeven te documenteren. Natuurlijk moet een bedrijfskritisch systeem goed zijn gedocumenteerd!

En wat mij betreft, áls we wat documenteren, documenteer dan tenminste de eisen waaraan de huidige werking van het product ten grondslag ligt. In permanente domeindocumentatie! Dit bespaart je in de regel enorm veel impact analyse werk om de delta vast te kunnen stellen!

Voor het ‘simplicity’ principe geldt wat mij betreft: Houd de delta documentatie beknopt en Lean. Verwijs waar mogelijk al naar (concept versies van) bestaande domeindocumentatie. Actualiseer de domein documentatie op het moment dat een feature of story wordt gerealiseerd, of vlak ervoor, of vlak erna (zie 2e figuur hierboven). Daarna kan de tijdelijke documentatie weg (cq. de stickie in de prullenbak).

Ook het streven naar kortere impact analyse doorlooptijden door gedisciplineerd bijhouden van baseline eisendocumentatie doet recht aan het 2e principe.

Het moge duidelijk zijn dat ik de roots van Dean Leffingwell een warm hart toedraag: requirements engineering en requirements management…;-)

Geïnteresseerd in meer kennis over SAFe? Volg de opleiding Leading SAFe ®4.6

 

 

Heeft u een vraag?

Neem contact op