Shared Understanding (2)
Vorige week gaf collega Piet de Roo het startschot voor een serie artikelen rondom het thema Requirements en Requirements Engineering. Dit is het eerste ‘inhoudelijke’ artikel in deze serie. We starten dit avontuur bewust met een wat vreemde eend in de bijt: Shared Understanding. Want waar veel termen binnen het vakgebied best duidelijk en strak omlijnd zijn is het begrip Shared Understanding (gedeeld begrip) een tamelijk vaag begrip als je er over nadenkt. Het klinkt heel logisch en telkens als ik er over begin tijdens trainingen, workshops of Agile Meetings knikt iedereen begripvol ‘Ja, natuurlijk! Logisch!’. Maar vraag iemand recht voor zijn raap wat het nu eigenlijk betekent en er zijn twee mogelijke uitkomsten:
- Een dodelijke stilte.
- Een lange discussie.
In dit artikel zal ik pogen uit de doeken te doen wat volgens mij bedoeld wordt met deze term.
Wat is Shared Understanding?
In de Syllabus IREB Certified Professional for Requirements Engineering Foundation Level staat de volgende toelichting op het begrip:
RE creates, fosters, and secures shared understanding between and among the parties involved: stakeholders, Requirements Engineers, and developers.
Hierin wordt gesteld dat onderdeel van Requirements Engineering is om te zorgen dat er een gedeeld begrip ontstaat bij alle betrokken partijen, te weten stakeholders, requirements engineers en ontwikkelaars. En tevens dat er gezorgd moet worden dat dit begrijp blijft bestaan. Er wordt vervolgens wel het één en ander uitgelegd over manieren om dit te bereiken (glossaries, prototypes, korte feedback loops) maar nergens wordt verteld wat Shared Understanding nu feitelijk is, noch wanneer er gezegd kan worden dat dit doel bereikt is.
Wanneer ik zelf de term hoor denk ik direct aan Gojko Adzic die de term al lange tijd gebruikt in vrijwel al zijn presentaties en boeken. Maar heel opvallend is dat als ik zijn boeken ‘Bridging the Communication Gap’ of ‘Specification by Example’ erbij pak dat zowel in de inhoudsopgave als in de Index de term niet eens voorkomt! Een boekenkast vol met boeken die gaan over dit onderwerp (The DevOps Handbook, Writing Great Specifications, The Goal, The Phoenix Project, The Unicorn Project, Work Rules), maar tot op heden ben ik nergens een goede definitie tegengekomen… En misschien is dat ook niet zo gek!
Het probleem (maar tegelijkertijd ook de kracht) van Shared Understanding is namelijk dat het geen exacte wetenschap is. Er is geen gouden formule met gegarandeerd Shared Understanding als uitkomst. Er is geen checklist die afgewerkt kan worden. Er bestaat geen Definition of Done die zegt wanneer we eraan voldoen.
Maar als niemand de vinger erop kan leggen wat het nu precies is, waarom vinden we het dan toch zo belangrijk?
Waarom Shared Understanding?
Binnen de softwareontwikkeling staat of valt, wat mij betreft, alles bij een gedeeld begrip. Het gehele betrokken team (Developers, inclusief de testers) weet waar een stuk nieuwe functionaliteit over gaat en nog belangrijker: waarom de wens of eis bestaat dit te realiseren. Dit is namelijk uitgebreid afgestemd met alle betrokken stakeholders, al dan niet via een requirements engineer en/of product owner. En niet enkel is helder waarom de wens/eis bestaat. Ook is bekend wie dit precies wil, wie er gebruik van gaat maken en wie er aanvullende belangen heeft bij de functionaliteit. We weten tot slot hoe de nieuwe functionaliteit het gedrag van deze actoren gaat veranderen en wellicht ook wat er gedaan moet worden om dit te gaan realiseren. Deze vragen, ‘Waarom?’, ‘Wie?’, ‘Hoe?’ en ‘Wat?’ zijn onderdeel van Impact Mapping (nog een boek van Gojko Adzic waarin de term Shared Understanding centraal staat maar niet voorkomt in inhoudsopgave of index!) en tevens van de bekende Golden Circle van Simon Sinek.
Pas wanneer alle betrokkenen een goed antwoord kunnen geven op deze vragen is er sprake van een begrip van de te ontwikkelen functionaliteit en wanneer al deze partijen ook nog eens hetzelfde antwoord geven op deze vragen is er sprake van een gedeeld begrip of Shared Understanding.
Maar wat hierin een ‘goed antwoord’ is? Niemand kan het vertellen…
Waarom is dit gedeelde begrip dan toch zo belangrijk? Omdat het een doel geeft waar naartoe gewerkt kan worden (zie het bekende werk van Goldratt, ‘The Goal’). Pas als alle partijen helder hebben wat het uiteindelijke doel is kan er gewerkt worden aan een effectieve wijze om dat doel te bereiken. Let wel, ik spreek hier over effectief en niet over effici?nt. Die twee kunnen een overlap hebben, maar effectiviteit gaat over het bereiken van het uiteindelijke doel met zo min mogelijk middelen (tijd, geld) waar effici?ntie slechts gaat over het beperken van middelen om een bepaalde (sub)taak te voltooien. Een taak die op zichzelf wel noodzakelijk kan zijn om het uiteindelijke doel te bereiken. Eén taak versnellen zal echter niet noodzakelijk het gehele proces naar het einddoel versnellen (Theory of Constraints).
Hoe te komen tot Shared Understanding?
Nu we weten wat er bedoeld wordt met Shared Understanding (zelfs zonder een strak omlijnde definitie) en waarom we dit willen rest nog de vraag hoe te komen tot dit gedeelde begrip.
Het antwoord daarop is niet eenvoudig te geven, maar wel kan er simpelweg gesteld worden dat het alles van doen heeft met communicatie en samenwerking (communication and collaboration). Met andere woorden: goed teamwerk. En dat is enkel te bereiken met respectievelijk vertrouwen, veiligheid, toewijding (commitment), krijgen en nemen van verantwoordelijkheid en voldoende aandacht voor het bereiken van resultaten (het doel bereiken). Zaken welke ook wel terug te vinden zijn in Lencioni’s ‘The Five dysfunctions of a team’. Wanneer een team binnen deze voorwaarden kan acteren is het vooral zaak een mindset te ontwikkelen waarin continu de vragen ‘Waarom?’, ‘Wie?’, ‘Hoe?’ en ‘Wat?’ gesteld worden én dat er een manier gevonden wordt om de antwoorden op deze vragen gestructureerd vast te leggen met zo min mogelijk ruimte voor eventuele misinterpretatie (het ‘secures’-gedeelte waarover gesproken wordt in de eerder aangehaalde IREB syllabus). De vorm waarin dit gedaan wordt is geen vast gegeven. Een effectieve wijze kan zijn het inzetten van Living Documentation (documentatie die ten alle tijden de actuele stand van zaken óf de actuele stand + 1 weergeeft en daardoor continu aan verandering onderhevig is) waarbij het gebruik van Specification by Example kan zorgen voor het concreet vastleggen van functionaliteit zonder ruimte voor misinterpretatie. Over deze beide thema’s heb ik eerder al artikelen geschreven en er zal nog meer volgen. Over de uitdagingen met betrekking tot het vastleggen van requirements in met name meer complexe omgevingen zal komende week een artikel te lezen zijn wanneer het stokje in deze artikelen reeks overgenomen wordt door collega Patrick Duisters. Welke architectuur en structuur kan/moet er gekozen worden met betrekking tot de vastlegging van requirements in dergelijke omgevingen? Verwacht geen hapklaar antwoord op deze vraag, want dat is er niet (wie het wel weet mag het zeggen!), maar een blik op de ‘strijd’ die gevoerd wordt om te komen tot een goede structuur of architectuur...
Dit artikel is een artikel in de reeks over het veelzijdige vak van Requirements Engineering waarbij de komende maanden iedere week een collega van Improve Quality Services de lezer meeneemt in de zaken waar de Requirements Engineer vandaag de dag tegenaan loopt. Elk artikel zal herkenbaar zijn aan de brug, de verbinding tussen twee oevers, die symbool zal staan voor ons vak: de verbinding tussen twee partijen die goed willen samenwerken, door goed te communiceren en die wij daar graag in willen helpen.