DREAM15

Dutch Requirements Engineering And ManagementDREAMagazineWWW.DREAMEVENT.NL

APRIL 2016

. .

DREAMagazine APRIL 20162

VoorwoordRedactioneel

ColofonDREAMagazine is een tijdschrift over Requirements Engineering. Het wil een platform zijn voor het uitwisselen en uitwerken van ideeënover het vakgebied.DREAMagazine verschijnt driemaal per jaar. Dit is nummer 11. Deze en de andere edities zijn te vinden op www.dreamevent.nl.Reacties en bijdragen kunnen gestuurd worden naar dreamagazine@dreamevent.nl.Redactie: Geertje Appel (ad interim), Linda Haak ­ van der Spek, Reinoud de Leve, Johan Oldenziel en Hans Siebering.Deze editie is tot stand gekomen dankzij bijdragen van: Mirjam van den Berg, Michiel Borgart, Fred Brandsma, Nataša Divljak, Erik Jansen,Katarzyna Kot, Garm Lucassen, Hidde Nieuwenhuijsen, Hans Post, Patrick Tangelder, Judith van Vorle, Jaap­Hein Vruggink en Jan­WillemZaalberg.

Bronverwijzing afbeeldingenPagina 23: http://www.youtube.com, http://www.kaapz.nl

Dit DREAMagazine is opgemaakt met Scribus 1.4.4 Open Source Desktop Publishing.

Donderdag 8 oktober 2015 werd in Vianen het zesdeDREAM event gehouden. In dit DREAMagazine

doen 11 bezoekers verslag van wat zij daar

hebben meegemaakt. Het zijn heel verschillende

persoonlijke verhalen geworden.

Johan Oldenziel behandelt in zijn rubriek Net geziende trends die hij tijdens het DREAM event heeft

waargenomen.

Paul Turner opende het event met een verhaal over

systeemdenken en werd daardoor de meest

geciteerde spreker van de dag. Geertje Appel interviewt

Debra Paul, een collega van Paul Turner bij Assist

Knowledge Development, over Pauls openingsspeech.

Theo Severien sloot de dag af met een verhaal over

zelfreflectie voor Business en Informatieanalisten.

Hans Siebering en Reinoud de Leve spraken na afloop

met hem over de kloof tussen business en IT,

DEMO en het Boeddishme.

Garm Lucassen hield op het event een verhaal over

het schrijven van betere user stories. In dit

DREAMagazine beantwoordt Garm vragen vanlezers over user stories. Hij geeft nuttige tips op

concrete problemen.

Arjen Uittenbogaard sprak op het event over over

zingeving voor requirements engineers. Wij

spraken met hem over zingeving, plezier belevenaan taaie vraagstukken en het vertellen vanverhalen.

Wij zijn bereikbaar:

dreamagazine@dreamevent.nl.

DREAM16 vindt plaats op 6 oktober 2016in Hotel Van Der Valk in Vianen

(onder voorbehoud, zie www.dreamevent.nl)

Het thema is:“Express Yourself! Visualisatie en modellering in Business Analyse

en Requirements Engineering”

DREAM15 3

Inhoud2 Redactioneel

Voorwoord4 Het DREAM event van Nataša Divljak

Zoals Paul vanochtend zeiNataša Divljak

5 Het DREAM event van Mirjam van denBergEr staan alleen maar mannen op hetpodium!Mirjam van den Berg

6 User StoriesGarm mag ik je wat vragen over UserStories?Garm Lucassen

10 Het DREAM event van Hans PostSokkenshow leerzaam en hartstikkeleuk!Hans Post

11 Het DREAM event van Judith van VorleVeel ervaring bij elkaarJudith van Vorle

12 Interview met Arjen UittenbogaardEr is niet één antwoordReinoud de Leve & Hans Siebering

16 Het DREAM event van HiddeNieuwenhuijsen'Hoe loopt jullie project? Goed hoor! Wedoen het namelijk volgens Scrum'Hidde Nieuwenhuijsen

18 Interview with Debra PaulScrum is in essence a development ofsystems thinkingGeertje Appel

20 Het DREAM event van Jan­WillemZaalbergVeelzijdige keuze aan sessiesJan­Willem Zaalberg

21 Het DREAM event van Jaap­HeinVrugginkBalans tussen zoom in en zoom uitJaap­Hein Vruggink

22 Net gezienOntdekkenJohan Oldenziel

24 Het DREAM event van Patrick TangelderZomaar met iemand in gesprek gaanPatrick Tangelder

25 Het DREAM event van Katarzyna KotBatterij opladenKatarzyna Kot

26 Interview met Theo SeverienEen methode heeft een theoretischmodel nodigReinoud de Leve & Hans Siebering

30 Het DREAM event van Erik Jansen enFred BrandsmaEen aantal mooie tracksErik Jansen en Fred Brandsma

31 Het DREAM event van Michiel BorgartGamificationMichiel Borgart

DREAMagazine APRIL 20164

Het DREAM event van Nataša Divljak

Als je mij wilt plagen, laat je me kiezen tussen meerdereinteressante dingen. Nou, ik had het moeilijk diedonderdag van het DREAM event. In elke sessie warener minstens twee presentaties die ik niet wilde missen.En alsof dat al niet genoeg was, kwam er nog eens hetpitch rondje bij. Toen ik bijna wilde iene­miene­muttenheb ik besloten om nog een paar requirements tebedenken zodat ik toch een keuze kon maken. Ik wildeiets leuks kunnen vertellen thuis aan de eettafel en ikging voor een mix van zowel jonge als oudere sprekers.Het uitgebreide verhaal over UX kan ik altijd nog lezen inhet laatste DREAMagazine, dus eindelijk had ik eenselectie.

Heb ik goede keuzes gemaakt? Jazeker. OK, ik vind hetjammer dat ik het verhaal over zingeving heb gemist enik had misschien de Brainwriting workshop moeten doenals ik iets direct volgende dag op mijn werk wildetoepassen. Maar, meer dan genoeg interessantsgehoord en gezien.

Ik heb het niet geturfd, maar weet bijna zeker dat hetmeest herhaalde zinsdeel deze dag was ‘Zoals Paulvanochtend zei...’. Logisch dat iedereen refereerdeaan deze ervaren spreker en zijn presentatie. Mettalloze voorbeelden en citaten bleef zijn verhaalhangen en had hij de hele tijd mijn aandacht.

Enige tijd geleden heb ik een zeer interessante lezingover het gamen in het onderwijs bijgewoond op deschool van mijn tienerzoon. Na deze eye­opener overmogelijk gebruik van gaming principes in hetonderwijs, was ik nu benieuwd naar de anderetoepassingen van games en game elementen. DeGamification presentatie was een goede introductiedaarvoor, ik vond met name leuk hoe je een killer,achiever, explorer of socializer het beste kuntbenaderen.

Het idee van een workshop alsenergizer na de lekkere lunch,werkte in het geval vanSpecification by Example nietomdat het aantalgeïnteresseerden veel te grootwas voor een workshop.Wellicht iets om een volgendekeer rekening mee te houden?

Naast de inhoud vind ik ookbelangrijk hoe een presentatieer uitziet. Het verhaal overfouten van Pieter was heel leuk en geestig opgezet.Maar het interessantst was de discussie na depresentatie: over het belang van certificering en depositionering van een business analist. Voornamelijk devraag van een collega BA over onvoldoende waarderingvoor ons beroep binnen haar organisatie: de businessbedenkt ideeën die ontwikkelaars realiseren, maar debusiness analisten? Ondanks dat ik dat in mijn omgevingniet zo ervaar, heeft het mij wel aan het denken gezet enheb ik besloten om de komende tijd daarop alerter te zijn.Misschien ligt een deel van het antwoord in deopmerking van Paul (turf), aan begin van zijn presentatie,dat een business analist alles doet wat men hem geeft tedoen (‘BA's do whatever people give them to do’).

Altijd leuk om ex­collega’s en andere bekenden weer tezien en natuurlijk een paar nieuwe vakgenoten tespreken. Geïnspireerd door de energie van jongesprekers, weer op de hoogte van nieuwe trends,gemotiveerd om eindelijk die IREB certificering te halen,ging ik met de nieuwste buzzwoorden en een paarboekentips tevreden naar huis.

De vraag van een collega BA overonvoldoende waardering voor onsberoep binnen haar organisatie: de

business bedenkt ideeën dieontwikkelaars realiseren, maar de

business analisten?

Zoals Paul vanochtend zeidoor Nataša Divljak

DREAM15 5

Vlak voor het DREAM event kreeg ik de vraag of ik naafloop een klein stukje wilde schrijven over wat mij ditjaar tijdens het event is opgevallen. En één ding viel mijeigenlijk direct op. Nog voor het event goed en wel vanstart was gegaan…

Nu zat ik naast een bekende, dus vroeg ik haar of haarook al iets was opgevallen. ‘Ja’, zei ze. En wat bleek,haar was precies hetzelfde opgevallen. Tijd voor eenklein journalistiek onderzoekje dacht ik. Dus na de eerstekeynote speaker en de eerste 8 pitches voor de parallelletracks, in de rij voor het damestoilet, vroeg ik een aantalvrouwen of hen ook iets was opgevallen. En ja hoor, ookhen was het al opgevallen.

‘Hmm, zou het dan toch iets zijn dat alleen vrouwenopvalt?’ Ook maar eens een paar mannen vragen. Enwat bleek? Alle mannen die samen met een vrouwelijke

collega naar het event waren gekomen zeiden meteen:‘Ja, er staan alleen maar mannen op het podium!’

Op naar de dames van deprogrammaraad: ‘Hoe komthet toch dat er dit jaar geenvrouwelijke sprekers in de line­up staan? Vorig jaar waren heter nog vijf. En als zo'n 25%van alle bezoekers vrouw is,dan zullen er toch ook wel eenpaar zijn met een interessantverhaal?’ En wat schetste mijnverbazing, het is al jaren heelmoeilijk voor de organisatieom vrouwelijke sprekers tekrijgen. Enerzijds omdatvrouwen niet of nauwelijks reageren op de ‘call forpapers’ en anderzijds omdat vrouwen die actief benaderdworden niet durven of zichzelf of hun verhaal nietgeschikt vinden.

Tsja dames, dan zullen we toch de hand in eigenboezem moeten steken. Als we zelf (meer) vrouwelijkesprekers willen, dan zullen we ook zelf in actie moetenkomen en de organisatie moeten gaan helpen doorpapers in te leveren, mogelijk interessante spreekstersaan te bevelen en over de (podium)angst heen testappen.

Ik kijk al uit naar de line­up van DREAM2016.

Er staan alleen maarmannen op het podium!

Het DREAM event van Mirjam van den Berg

Mirjam van den Berg is trainer en coach in heldere

communicatie over requirements in de IT. In 2011

richtte zij haar eigen bedrijf Bridging Minds op. 'Mijn

kracht is dat ik het zelf gedaan heb. Ik weet

waarover ik praat. Er zijn wel anderen die

trainingen in Soft Skills geven, maar er zijn er geen

die net als ik uit de praktijk komen.'

Mirjam was spreekster op DREAM14.

door Mirjam van den Berg

DREAMagazine APRIL 20166

Beste Garm,Ik werk in een vrij complexe omgeving. Binnen dezeomgeving is het niet mogelijk om een user story in éénsprint naar productie of acceptatie te brengen. Daar gaannog flink wat sprints over heen. Voor het team is éénuser story meerdere sprints werk. Voor hen is de userstory meer een epic. Vanuit de gebruiker gezien, is deuser story niet verder op te splitsen, omdat je dan ietsover houdt dat op zich geen waarde meer heeft. Ikgebruik zelf graag het begrip user story slice. Je kunt opverschillende manieren een user story op delen in slices,maar dat gaat al gauw de richting uit van functioneledecompositie. Kortom wat doe je als user stories te grootzijn voor het team om in een sprint of enkele sprints op tepakken?Reinoud de Leve

Beste Reinoud,In “User Stories Applied” predikt Mike Cohn “It is better tohave more stories than to have stories that are toolarge”. Om vast te stellen wanneer een user story tegroot is, gebruik ik bij voorkeur complexity points in

combinatie met de Fibonacci reeks. Iedere stap in hetontwikkelproces telt als één complexity point en een userstory met 13 punten dien je verder op te splitsen. Eensimpele methode om een formulier in te dienen, moetontwikkeld, getest en opgemaakt worden. Dat is al 3punten. Is er ook nog een database migratie nodig? 5punten.

De user stories worden dan inderdaad functioneel. Mitsje ze samen met de developers opstelt in een refinementsessie vlak voordat ontwikkeling aan de epic van startgaat is dat helemaal niet erg. Belangrijk is wel dat dedevelopers op de hoogte blijven van het beoogde doelvan de epic. De gebruiker of klant hoeft van het bestaanvan de kleinere user stories niet te weten. Sprint teneinde maar de epic is nog niet af waardoor er geenconcrete business value is om te leveren aan degebruiker? Geen probleem! Aan het eind van een sprinthoor je een potentially shippable product op te leveren.Alle ontwikkelde features zijn netjes afgemaakt en

Garm mag ik je wat vragenover User Stories?Vroeger beantwoordde Mona in de Story de vragen van lezers. Vragenover eenvoudige praktische problemen “Lieve Mona, hoe krijg ikvetvlekken uit mijn witte blouse?” en vragen over moeilijke keuzes enbeslissingen “Lieve Mona, mijn man tennist met mijn beste vriendin ...”.In navolging van Mona laat het DREAMagazine een deskundige devragen van haar lezers beantwoorden. Deze keer kruipt Garm Lucassenin de huid van Mona. Hij beantwoordt vragen van lezers over UserStories.

User Stories

door Garm Lucassen

Iedere stap in het ontwikkelprocestelt als één complexity point en een

user story met 13 punten dien jeverder op te splitsen.

Aan het eind van een sprint hoor jeeen potentially shippable product opte leveren. Alle ontwikkelde featureszijn netjes afgemaakt en technischgezien zou je een nieuwe versie

kunnen leveren, maar dit hoeft niet.

DREAM15 7

technisch gezien zou je een nieuwe versie kunnenleveren, maar dit hoeft niet. De product owner beslistwanneer je daadwerkelijk released. Of dit na 1 of na 10sprints is, maakt niet uit.Groet,Garm Lucassen

Beste Garm,De product owner is in scrum verantwoordelijk voor derefinement van de user stories. Als men mij vraagt wie derefinement uiteindelijk moet doen, antwoord ik altijd datde product owner dat in samenwerking met het teammoet doen. De vraag is of dat altijd kan. Vooral als deproduct owner veel te druk is.Kan het team ook zonder de product owner derefinement van de user stories doen? Wat zijn daarvandan de voor­ en nadelen?Els Verkaik

Beste Els,Tsja, alles is natuurlijk mogelijk. Raadzaam is eentweede. Het team een refinement laten doen zonderproduct owner heeft namelijk voornamelijk nadelen. Hetteam doet verkeerde aannames, antwoorden op

prangende vragen laten te lang op zich wachten ofblijven volledig onbeantwoord.

De prettigste oplossing is om een tweede product ownerof een andere product owner met meer tijd te vinden. Alsdit niet mogelijk is, is het raadzaam om te overleggenmet de product owner hoe zijn of haar tijd zo effectiefmogelijk in te zetten.Groet,Garm Lucassen

Beste Garm,Wanneer is een user story voldoende uitgewerkt (ready)om op te pakken in een sprint? Dat blijf ik een lastigevraag vinden. Als je te ver de details in duikt, wordt het algauw een upfront design. Dat is meer de aanpak van dewaterval methode. Echter als de user story te weiniggedetailleerd is, leidt dat tot veel vragen en daarmee totwachttijd in de sprint.Heb jij handvatten of tips waardoor ik beter kan bepalenwat goed genoeg is?Els Verkaik

Beste Els,Een veelgestelde vraag met meerdere perspectieven.Ron Jeffries, één van de grondleggers van eXtremeProgramming, stelt dat een user story bestaat uit eenCard, Conversation en Confirmation. De Card fungeerthier als een verwijzing naar de inhoud van deConversation die je hebt met relevante stakeholders omvast te stellen wat je daadwerkelijk gaat bouwen. DeCard bevat precies genoeg informatie om de requirement

Garm Lucassen

Garm Lucassen is promovendus aan de Universiteit

Utrecht. Hij doet onderzoek naar methoden,

processen en tools die software development

ondersteunen. Bij voorkeur in de context van

innovatieve software producten. In het bijzonder richt

Garm zich nu op user stories, waarbij hij een antwoord

probeert te vinden op de vraag of de inherente

kwaliteit van user stories effect heeft op het software

development process alsmede de resulterende

software. Lees meer over zijn onderzoek en hoe je

eraan kunt bijdragen op garmlucassen.nl

Daarnaast organiseert Garm in samenwerking met

prof. dr. Sjaak Brinkkemper tweemaal per jaar de

cursus software product management. Gedurende

tien sessies leren cursisten hoe software product

management effectief in te vullen in een snel

veranderende, agile werkomgeving. Lees meer over

de cursus en het behalen van het ISPMA Foundation

Level Certificate op

http://www.softwareproductmanagement.org/

Het team een refinement laten doenzonder product owner heeft namelijk

voornamelijk nadelen.

DREAMagazine APRIL 20168

te identificeren, niets meer. Dit mag dus ook één woordzijn: “registratie” bijvoorbeeld. Om vast te stellen ofdatgene wat je gebouwd hebt voldoet aan de wensenvan de klant, definieer je samen met de klant acceptancetests als Confirmation.

Volgens de Extreme Programming denkwijze is deconversatie rondom een user story dus veel belangrijkerdan het document van de user story zelf. In de dagelijksepraktijk is het echter zelden zo simpel. Niet ieder teamkán op deze manier werken en lang niet iedere klant isbereid op deze manier te werken. Desalniettemin blijktkeer op keer dat user stories uiteindelijk een middel zijnom heldere communicatie tussen je stakeholders tefaciliteren, in plaats van het doel op zich. Het is dus vanbelang om met je stakeholders te bespreken wat zij hetprettigst vinden werken. Het is vervolgens jouw taak alsRequirements Engineer om het leven van zowel je klantals developers zo gemakkelijk mogelijk te maken.

Opmerkelijk is dat volgens deelnemers aan onsonderzoek naar user stories ver uitgewerkte user storiesniet per definitie verkeerd zijn. Integendeel, jonge teamsdie onervaren zijn met software development en/of userstories hebben vaak júist baat bij gedetailleerde userstories. Na verloop van tijd gaat het team hier minderbehoefte aan hebben en kun je het detailniveauterugschalen naar enkel het user story sjabloon +acceptance tests.Groet,Garm Lucassen

Beste Garm,In mijn project maken we APIs die door verschillendepartijen worden afgenomen. Dat kunnen partijen binnen,maar ook buiten ons bedrijf zijn. Wij gebruiken userstories om de requirements voor het (scrum) team vast teleggen. De user stories vormen de basis voor de bouw.We proberen door middel van acceptatiecriteria ookvoldoende informatie vast te leggen voor de (gebruikers)testers. Wat bij ons ontbreekt, is documentatie voor deafnemers van de APIs. Wat is, als je met user storieswerkt, de geëigende manier om dit te documenteren?Rita Ahlers

Beste Rita,Helaas is het onderwerp documentatie en user stories inde academische wereld nog grotendeels onontgonnengebied. Toevallig zijn we bij de Universiteit Utrecht op het

moment aan het verkennen of het mogelijk is om userstories en documentatie te koppelen alsmede genereren,maar voorlopig is dit nog toekomstmuziek.

Vanuit de praktijk zien we verschillende aanpakken. Dedeveloper schrijft een stukje tekst nadat zij de user storyvoltooit. Of juist voordat hij überhaupt begint.Documentation Driven Development is bijzonder zinnig inde context van APIs. Vaak gebeurt het echter gewoonniet. Totdat er iemand klaagt dat de huidige APIdocumentatie niet meer klopt.

Grote bedrijven in de Verenigde Staten hebben vaak eenspecifiek iemand aangesteld die onder andereverantwoordelijk is voor de kwaliteit en uniforme stijl vande API documentatie: een Developer Evangelist. Voorveel bedrijven in Nederland is dit waarschijnlijk nogtoekomstmuziek. Bekijk dan de verzameling van bronnenop de blog van Parse voor inspiratie om in ieder gevalintern duidelijke afspraken te maken van hoe jullie APIdocumentatie er uit dient te zien!Groet,Garm Lucassen

Beste GarmIk werk in een team dat een front end applicatiebouwt/beheert, die users de mogelijkheid biedt om in techecken voor een vlucht. Een ander team levert ons ­ enandere front end applicaties ­ functionaliteiten doormiddel van een API. Die API roept op zijn beurt weer eenandere applicatie aan. Als ik voor ‘mijn applicatie’ eenuser story schrijf, dan kan dit een wijziging betekenen inzowel ‘mijn applicatie’ als de onderliggendeapplicatie(s).1. Hoe beschrijf ik dat? Moet ik een user story maken perapplicatie? Elke applicatie kan een deel van defunctionaliteit van de wijziging bevatten.2. De wijziging kan ook leiden tot een gewijzigdefunctionaliteit van de andere front end applicaties. Hoemoet ik hier mee om gaan?Rita Ahlers

Beste Rita,Leuke vraag over een bijzonder ingewikkelde omgeving!Als ik het goed begrijp zijn er vanuit jouw oogpunt vier

Jonge teams die onervaren zijn metsoftware development en/of userstories hebben vaak júist baat bij

gedetailleerde user stories.

User Stories

Documentation Driven Developmentis bijzonder zinnig in de context van

APIs. Vaak gebeurt het echtergewoon niet. Totdat er iemand klaagtdat de huidige API documentatie niet

meer klopt.

DREAM15 9

Garm Lucassentypes product owner die verantwoordelijk zijn voor userstories:1. Jij als product voor jouw front­end application2. De product owner van de API3. De product owner van de onderliggende applicatie

van de API4. Product owners van alle andere front­end applicaties

Jouw eerste verantwoordelijkheid is om je productvisieom te zetten in relevante en bruikbare user stories. Somszullen jouw user stories een wijziging vereisen in deonderliggende API. De volgende stap is om dit tecommuniceren naar product owner type 2. Dit kanuiteraard middels een user story, al dan niet dezelfde dieje gebruikte voor je eigen applicatie. In de meestegevallen zal dit echter niet voldoende descriptief zijn.Moet je dan een aparte user story maken per applicatie?Niet per se. De verantwoordelijkheid hiervoor ligtnamelijk bij de product owner type 2, een belletje of eenmailtje om je wensen duidelijk te maken is dusvoldoende! Het is vervolgens de taak van product ownertype 2 om te beoordelen of jouw wens past binnen deAPI, of zij daarvoor een user story gaat maken en of zijde type 3 product owner moet betrekken om jouw wenste kunnen voldoen.

Het is natuurlijk mogelijk dat jij naast product owner type1 ook de verantwoordelijkheid hebt voor type 2 en 3. Ditheeft echter geen gevolgen voor het conceptueleonderscheid. Wanneer een user story voor type 1 impactheeft op de applicatie van type 2 of 3, dien je met eenfrisse, kritische blik te beoordelen of de vereiste eisrelevant genoeg is voor de API in het algemeen. Zo ja,dan doe je er vaak goed aan om een aparte user story temaken die beter past in de standaardtaal van de API ofde onderliggende applicatie. Heeft de veranderinggevolgen voor product owners van type 4? Informeer hendan zo goed mogelijk en laat het schrijven van eventueleuser stories aan hen over.Groet,Garm Lucassen

Beste Garm,Wat doe je met de befaamde zin "Ik als ...." als het niettriviaal is wat je op de puntjes moet invullen. Het is eenfunctie die niet een concrete identficeerbare gebruikerheeft. De functie vloeit voort uit wet­ en regelgeving, ofuit de manier waarop het systeemlandschap is ingericht.De functie wordt door iedereen gebruikt: medewerkers,klanten, derden. Ik stuit af en toe op situaties waarbij deformulering "Ik als ...." gekunsteld overkomt. Wat is jouwadvies in zo'n situatie.Reinoud de Leve

Beste Reinoud,Soms is het helemaal niet zo erg om een gekunsteldeuser story te formuleren. De volgende user story voeltbijvoorbeeld vreemd aan, maar is niets mis mee: “As aSupermarket, I want to receive a summary of deliveredgoods, so that I know what products are in stock”. Hethumaniseren van een entiteit zoals een organisatie ofeen ding is niet per definitie verkeerd! Desalniettemin zijner soms situaties waarin een user story eigenlijk niet zo

geschikt is om de requirement in uit te drukken. MikeCohn suggereert dat wanneer je functionaliteit beschrijftdie niets met echte gebruikers te maken heeft engeforceerd het user story formaat gebruiken vreemdvoelt je beter een alternatieve vorm kunt kiezen. MikeCohn suggereert Feature­Driven Development van Jeffde Luca (1997), waarbij je features uitdrukt als:

<action> the <result> <by|for|of|to> <object>

Bijvoorbeeld:­ Change the text of login button­ Back up the user data to cold storage­ Update the database character encoding to UTF­8

User stories zijn dus niet een soort magische techniekdie al je problemen oplossen. Houd altijd je ogen openvoor eventuele betere alternatieven voor jouw situatie.Zelfs Mike Cohn suggereert dus een alternatief voorsommige situaties. En hij heeft user stories grootgemaakt! De laatste tijd horen wij bijvoorbeeld steedsmeer over Job Stories. Zeker ook de moeite waard omeens tien minuten over te lezen.Groet,Garm Lucassen

Mike Cohn suggereert dat wanneerje functionaliteit beschrijft die niets

met echte gebruikers te maken heeften geforceerd het user story formaatgebruiken vreemd voelt je beter een

alternatieve vorm kunt kiezen.

Probleem bij User Stories

Oplossing: Job Stories

DREAMagazine APRIL 201610

De ochtend van het DREAM event begon met eenkeynote van Paul Turner, Director of Assist KnowledgeDevelopment. Hij sprak over Systems Thinking, wat opzich een verwarrende term is. Het staat voor het op eenholistische manier kijken naar een systeem in zijngeheel, waarbij een systeem altijd weer deel uitmaaktvan een groter systeem, en we niet over IT­systemenpraten maar over alles omvattende systemen waar ookmensen deel van uitmaken. Wat in een systeem gebeurtheeft daarom altijd effect daarbuiten, en voor een BA ishet belangrijk dit altijd te beseffen! Tegenwoordig zijn demeeste ICT­ers ergens in gespecialiseerd en wordthelemaal niet gekeken naar het geheel. Zijn boodschap:“Don’t think about the here and now but where you camefrom and where you want to go.” Deze andere maniervan tegen systemen aankijken vergt een geheel anderementale instelling maar kan tot verrassende oplossingenleiden. Hij noemde als voorbeeld dat er huizen zijn dieworden verwarmd door er servers in te zetten en derestwarmte te gebruiken. ’Think outside the box, whatbox?’ is een gevleugelde uitspraak van Paul in dit kader.Als belangrijkste advies aan BA’s gaf hij mee dat hetbelangrijk is om alle stakeholders van een systeem tespreken en al hun verschillende perspectieven van dewerkelijkheid te leren kennen. Paul Turner heeft over BAhet volgende boek geschreven, samen met James Cadleen Debra Paul: ’Business Analysts Techniques. 99essential tools for succes’.

Marcel Steur: ’Requirements verzamelen inagile, hoe ver moet je gaan’In deze parallelsessie hield Marcel Steur van Qquest eenverhaal over een onderzoek dat hij heeft uitgevoerd bijhet Centraal Boekhuis naar de benodigdegedetailleerdheid van requirements in verschillendeprojecten die daar zijn uitgevoerd. Zijn aanpak hield indat hij allerlei aspecten van de verschillende projecten ende verschillende teams waardeerde met een kengetaltussen 0 en 5. Zo bekeek hij van teams o.a. degrondhouding (0 = negatief, 5=zeer positief), defunctionele en de technische skills en van projecten(grootte, risico, complexiteit). Al deze kengetallen stoptehij in een formule en die leverde op hoe gedetailleerd derequirements moeten zijn. Hoe hoger de uitkomst hoemeer gedetailleerd. Meest gedetailleerd kwam neer opzodanig gedetailleerde user stories dat het bijna op eentechnisch ontwerp lijkt. Interessant was dat hij met dezeformule historisch onderzoek heeft gedaan naar verrichteprojecten waaruit bleek dat deze formule een primamaatstaf is die bij nieuwe projecten gebruikt kan wordenom een eerste inschatting te doen van de mate vangedetailleerdheid. Uiteraard kan er dan binnen een Agileaanpak altijd weer worden op­ of afgeschaald. Ik vondhet het interessantste verhaal van de dag, en eenwetenschappelijke publicatie waardig.

Arjen Uittenbogaard: ‘Zingeving voorRequirements Engineers’Arjen staat bekend als iemand die het vak van businessof information analyst van verrassende kanten bekijkt;soms op een filosofische manier. Twee jaar geleden hebik hem al een keer gezien op het DREAM event en ookdeze keer stelde hij niet teleur met zijn bijdrage. Dezekeer sprak hij over complexe organisaties waar jevolgens hem absoluut niet moet werken met bestpractices en al helemaal niet met templates. Hij pleitervoor om vooral kleine stappen te zetten en daarbijvooral zelf na te denken wat je nodig hebt. Hij beriep zichop het zgn. Cynefin raamwerk van Dave Snowden en hetboek ‘Plezier beleven met weerbarstige vraagstukken’van Hans Vermaak (nee, die naam is niet verzonnen…).In het genoemde raamwerk worden uitsprakengehanteerd als ‘Prevent premature convergence’ (als jehet te snel met elkaar eens bent, heb je dan wel alle

Het DREAM event van Hans Post

'Think outside the box, what box?'

Sokkenshow leerzaam enhartstikke leuk!door Hans Post

DREAM15 11

invalshoeken bekeken?) en ‘find dissensus instead ofconsensus’ (daag mensen uit om het vooral niet metelkaar eens te zijn op het professionele vlak (niet op hetpersoonlijke vlak!!). Zaken om echt eens over na tedenken!! Nog een tip van hem: Vraag deelnemers aaneen scrum eens iets te vertellen over wat ze hebbenmeegemaakt, iets gaafs of juist een blunder die zebegaan hebben.

Philippe van Hees: ‘De Sokkenshow –Workshop’Van een geheel andere orde was de Sokkenshow!!Eigenlijk was het een workshop onder leiding vanPhilippe van Hees van De Processpecialisten. Dedeelnemers werden opgedeeld in twee teams die elk eensokkenfabriek moesten simuleren. Er was iemand dieopdrachten in ontvangst moest nemen van klanten zoals:Ik wil graag 10 paar nylonkousen, 20 paar zwarte sokkenen 15 paar witte sokken. Op een tafel (de ‘productielijn’)lag een grote stapel nylonkousen en verschillendekleuren sokken die Philippe had meegenomen, kris krasdoor elkaar. Langs de productielijn stonden orderpickers, assemblers en packagers. De ene fabriek stondbekend om zijn hoge snelheid maar lage kwaliteit, bij detweede fabriek was het precies andersom. En tijdens hetleveren van de opdracht kwamen regelmatig nieuweopdrachten binnen. Uiteindelijk werden de teamsbeoordeeld door de opdrachtgevers op snelheid enkwaliteit, maar ook op communicatie. Kun je jevoorstellen hoe dit ging? Mensen die langs elkaar heenwerken, slechte communicatie, slechte afstemming vanprocesstappen, etc. In heel korte tijd zie je hoe belangrijkhet is om goede processen in te richten, iets waarbusiness analisten natuurlijk alles van weten! Heelleerzaam en hartstikke leuk!

Het DREAM event van Judith van Vorle

Ook al zit ik jaren in het ‘vak’ als business analist, ik washelaas nog niet eerder op een congres / beurs geweestvoor vakgenoten. En ik kan je nu al vertellen: wat heb ikdan veel gemist! Wat een genot om zoveel vaktijgers teontmoeten en zoveel ervaring bij elkaar te zien.

De reden voor mij om het DREAM event te bezoekenwas vooral het ontmoeten van vakgenoten, maardaarnaast ook zeker om (nieuwe) ontwikkelingen in hetvak te horen. En horen van ‘klanten’ hoe zij omgaan metrequirements(management), agile, Scrum en de rol vande business analist daarin.

Ik bezocht allereerst de presentatie van de ProvincieOverijssel, omdat zij daar met basisregistraties bezig zijnen daar ben ik nu ook bij de Provincie Zuid­Holland meebezig. Enerzijds vond ik het prettig om te zien dat zijtegen dezelfde zaken aanlopen als ik bij Zuid­Holland(namelijk: hoe haal je requirements op bij de businessdie niet altijd heel positief tegenover de basisregistratiesstaat). Anderzijds jammer dat je daardoor weinig nieuweideeën ophaalt om te gebruiken.

Na een overheerlijke lunch en gelegenheid tot netwerken(ik zag diverse bekenden, altijd leuk) heb ik desokkenworkshop bezocht. Een hilarische manier om metje neus op de feiten gedrukt te worden, die zorgde voorde nodige ontspanning tijdens deze verder vrij serieuzedag. In de sokkenworkshop wordt duidelijk dat je alsorganisatie snel de bocht uit vliegt als je pretendeert deklant voorop te zetten. Wat betekent dat nou écht? Ikheb het antwoord nog niet, en elke casus is anders,maar deze sokkenworkshop vergeet ik niet snel!

De presentatie van de NS over ‘Hoe borg jerequirements engineering in een grote organisatie?’ vondik inspirerend. Al bijna 10 jaar doe ik opdrachten bij groteorganisaties en dus herkende ik veel in wat Sven van derZee vertelde. Het lijkt me echter nog steeds eenuitdaging om in een dergelijke grote organisatie iedereendezelfde richting op te krijgen. In hoeverre blijven er tochniet eigen koninkrijkjes met eigen werkwijzen bestaan?Dat zul je, denk ik, daadwerkelijk bij NS op de werkvloermoeten ervaren.

Veel ervaringbij elkaardoor Judith van Vorle

DREAMagazine APRIL 201612

Je begon je presentatie op het DREAM eventmet de uitspraak dat jij requirementsengineering eigenlijk een heel foute term vindt.Waarom is de term requirements engineeringzo fout?

Ik ben altijd al gevoelig geweest voor taal. De laatste tijdbegin ik steeds meer te letten op wat er gebeurt alsmensen de verkeerde woorden gebruiken. Welkebeelden roept dat op? Requirements engineering vind ikeen typisch voorbeeld van een verkeerd gekozencombinatie van woorden. Met engineering kun jeuitrekenen of een brug sterk genoeg wordt om ervrachtwagens overheen te laten rijden als je draagkrachtvan een boogconstructie kent en het gewicht van ijzer,rekening houdend met de zwaartekracht. Het is eenharde wetenschap. Het antwoord op een vraag kun jeaan de hand van de juiste wiskundige formulesberekenen.

De term requirements engineering doet vermoeden datwe met requirements iets vergelijkbaars doen. En dat ishelemaal niet het geval. De complexiteit bij requirementszit er nou juist in dat de klant van tevoren niet preciesweet wat hij wil, dat je vaak op zoek moet naar het echteprobleem, dat je de klant een oplossing presenteert endat de klant ontdekt dat hij toch iets heel anders wil. Datis geen verwijt aan de klant, maar de realiteit. Decomplexe wereld waarin wij werken, vraagt om een heelandere aanpak dan engineering. Ons werk is geen hardewetenschap. Er is geen vast stappenplan. Er is niet éénantwoord.

Paul Turner trok in zijn openingsspeech een vergelijkingmet Michelangelo die zou hebben gezegd dat hij in elkstuk marmer al een compleet beeld voor zich zag. Het

Er is niet één antwoordArjen Uittenbogaard is vaak op het DREAM event aanwezig geweest alsspreker. Zo ook op DREAM15. Zijn presentatie ging over “Zingevingvoor Requirements Engineers”. Voor ons een mooie aanleiding voor eeninterview.

Interview

door Reinoud de Leve en Hans Siebering

De complexe wereld waarin wijwerken, vraagt om een heel andereaanpak dan engineering. Ons werk

is geen harde wetenschap. Er isgeen vast stappenplan. Er is niet

één antwoord.

DREAM15 13

enige wat hij had te doen was het beeld bevrijden doorhet overtollige steen weg te hakken. Paul Turner voegdeer wel aan toe dat dat alleen was weggelegd voorgenieën. Ik geloof niet zo in deze vergelijking. Los vanhet feit dat maar weinigen onder ons een genie zijn,veronderstelt deze vergelijking dat het resultaat al vantevoren vast ligt. Het is een beetje vergelijkbaar metmensen die zeggen dat ze de requirements moetenverzamelen, alsof de requirements ergens voor hetoprapen liggen. Zij houden er geen rekening mee datrequirements juist in de loop van het project ontstaan enveranderen. In een complexe wereld is het beter om hetmet elkaar eens te worden over de richting waarin je jegaat bewegen en dan kleine stappen te doen, dan je tefixeren op één punt op de horizon. Een punt op dehorizon is veel te precies.

In plaats van engineers zijn we volgens jouvaak onbewust een soort kwakzalvers.Wanneer maken we ons schuldig aankwakzalverij?

De kwakzalver gelooft in een lineair verband tussen hetmiddeltje dat hij zijn patiënt heeft voorgeschreven en degenezing die daarop volgde. Als één keer een patiënt isgenezen nadat hij zijn ochtendurine heeft gedronken, zalde kwakzalver steeds opnieuw patiënten voorschrijvenhun ochtendurine te drinken in de heilige overtuiging datdat zal helpen. De kwakzalver doet daarmee geen rechtaan de complexiteit van de wereld. Hij ziet niet in datbuiten de ochtendurine ook andere factoren kunnenhebben bijgedragen aan de genezing van de patiënt.Misschien heeft bij nader inzien de ochtendurine geenenkele rol van betekenis gespeeld. Wie zal het zeggen?Het oorzaak­gevolg­denken van de kwakzalver is veel tesimplistisch.

Er zijn vrouwen in Afrika die een blad in de emmer waterdoen die zij op hun hoofd naar het dorp dragen, omdat zijgeloven dat ze daardoor minder water onderweg zullenmorsen. Het feit dat de vrouwen niet weten waarom hetblad voorkomt dat zij water morsen, maakt het voor mijnog niet tot kwakzalverij. Je kunt best de goede dingendoen, zonder dat je de juiste oorzaak daarvan weet.Het wordt pas kwakzalverij als je bij een complexprobleem een lineair verband suggereert tussen eenmiddel en een resultaat. Wij doen dat als we methodenen technieken waarmee we succesvol zijn geweest in het

ene project, voorstellen als de oplossing voor deproblemen in een ander project. Het is namelijk gewoonniet waar dat iets wat succesvol was in de ene situatieautomatisch ook succesvol zal zijn in een anderesituatie. Zo zit de wereld niet in elkaar. Er is nooit éénoorzaak voor het succes.

Ik vind dat we daarom ook beter niet over best practicesmoeten spreken. We kunnen het hooguit over goodpractices hebben. Het woord best doet vermoeden dathet altijd zal werken. Daarom zijn best practicesmisschien wel een vorm van kwakzalverij.

Tegenwoordig omarmen veel organisaties eenagile werkwijze. Is agile nu ook een vorm vankwakzalverij?

Bij Altimos hebben we op onze visitekaartjes staan:“persoonlijk agile veranderen”. We hebben nog een flinkediscussie gehad of we het woord ‘agile’ zoudengebruiken. We hebben ervoor gekozen om het wel tedoen, maar uiteindelijk gaat het ons om verbetering vanmensen, teams en organisaties. Het agile gedachtegoedis daarbij een goed uitgangspunt. “Responding to changeover following a plan” is een verstandige grondhoudingals je ervan uitgaat dat de wereld veranderlijk is. Het isgeen oplossing, geen silver bullet, maar het geeftrichting. Zo kijk ik ook tegen de andere principes uit hetAgile Manifesto aan. Een vuistregel als ‘INVEST’ zie ikniet als een hard criterium voor een goede user story.Het zijn voor mij meer aandachtspunten bij een goedediscussie over de user story. Agile sluit wat dat betreftheel goed aan op de werkingsmechanismen waarover ikop het DREAM event heb gesproken.

Als jullie bedoelen dat organisaties er soms denken tezijn als ze iedere morgen een stand­up houden en aanhet eind van iedere sprint een retrospective, dan heb jegelijk. Als je alleen de dingen doet zonder dat je goedweet waarom je de dingen doet, verbeter je misschienwel iets, maar gaat het nooit echt vliegen. Daarbij werkthet vaak goed om eerst een bepaalde discipline aan eenteam op te leggen. Als coach vraag ik in het begin aanhet team de dingen te doen omdat ik het zeg. Dat is mijnvakmanschap. Ik weet namelijk dat dat de goedediscussies gaat opleveren. Daarnaast stimuleer ik hetteam om kritisch te blijven nadenken. Het stimuleren vansubversiviteit kan heel positief werken. Projectmanagersvinden dat niet altijd leuk, maar ik vind dat als het teamvindt dat bepaalde dingen niet werken, ze er mee opmoeten houden om iets anders uit te proberen watmogelijk wel werkt. Meestal stel ik voor om dat dan te

Arjen Uittenbogaard

In een complexe wereld is het beterom het met elkaar eens te wordenover de richting waarin je je gaat

bewegen en dan kleine stappen tedoen, dan je te fixeren op één punt

op de horizon. Een punt op dehorizon is veel te precies.

DREAMagazine APRIL 201614

Interviewdoen voor een paar sprints en steeds in de retrospectivete bekijken of het wel werkt.

Het mooie aan Scrum is dat de sprint zelf geen complexewerkelijkheid meer is. Een sprint is het werk dat je gaatdoen in de komende twee weken. Daar is niets complexaan. De complexiteit bevindt zich juist buiten de sprint,waar je rekening moet houden met verschillendestakeholders, met ieder hun eigen belangen. Het zijnvooral de product owners die moeten kunnen omgaanmet die complexe werkelijkheid.

In een complexe wereld waarin je te makenhebt met politiek, conflicterende belangen vanstakeholders, samenwerking met tal vanandere partijen krijg je te maken metweerbarstige patronen. Jij gebruikt in jepresentatie de term ‘Werkingsmechanisme’.Kun je uitleggen wat dat is?

De term werkingsmechanisme ontleen ik aan het boek‘Plezier beleven aan taaie vraagstukken’ van HansVermaak. Hij beschrijft daarin een aantal weerbarstigepatronen die je tegenkomt bij groteveranderingstrajecten. Bij weerbarstige patronen is er

een onbewuste, dominante houding die de veranderingin de weg zit. Vermaak legt uit welke dynamiek ervoorzorgt dat dit patroon in stand wordt gehouden en wat jedaar tegenover kunt zetten om dat te doorbreken. Datdoet hij met werkingsmechanismen die je per situatiemoet vormgeven met technieken en werkwijzen. Hij geeftverschillende typen werkingsmechanismen: voorinteractie (hoe werken we samen?), cognitie (hoe kijkenwe naar de wereld?), procesontwerp (hoe gaan weveranderen?) en procesverankering (hoe houden we deverandering in stand?).

Een voorbeeld van een weerbarstig patroon bij interactieis ‘dwingen & duiken’. Je ziet het al voor je. Als jeprobeert met dwang mensen beter met elkaar te latensamenwerken, ontwikkelen mensen allerlei techniekenom onder die dwang uit te komen. Een weerbarstigpatroon bij cognitie is ‘enkelvoudige perspectieven &anekdotische kennis’. Je kunt dat doorbreken door hetintroduceren van, en dat is dan eenwerkingsmechanisme, ‘cognitieve diversiteit’. Je laatmensen op een andere manier naar het vraagstuk kijkendoor bijvoorbeeld andere metaforen of andere modellente gebruiken. Een weerbarstig patroon dat wij vaak in onswerk zien is ‘onbetwiste waarden’. Intuïtief zegt iedereprogrammamanager dat we moeten streven naareenheid, beheersing, stabiliteit en meetbaarheid. Dat zijnallemaal onbetwiste waarden. Hans Vermaak legt uit water mis is met die waarden en dat je ze bijvoorbeeld kuntdoorbreken door ‘problematisering’: je gaat vragen wathet nou werkelijk oplevert als we dingen meetbaargemaakt hebben. Wat levert dat ons op? Gaat hetdaardoor nou echt veel beter? Humor is een andere. Danga je de draak steken met de onbetwiste waarden. Eenbeetje als een nar.

Het stimuleren van subversiviteitkan heel positief werken.

Arjen Uittenbogaard is coach, trainer en facilitator. Hijhelpt coaches, professionals, teams en organisatiesmeer agile te werken. Daarbij put hij uit de hardetechnieken van requirements engineering en objectgeoriënteerd ontwikkelen. Maar bovenal adresseert hijsteeds weer de zachtere technieken van samenwerken,communicatie en leiderschap. Hij weet dat veranderenin complexe omgevingen niet­intuïtief is en helpt blindevlekken op te sporen en valkuilen te vermijden. Arjen iseen prijswinnend en gewaardeerd spreker.

In september 2015 begon Arjen met vier ervarencollega’s hun bedrijf Altimos. Altimos helpt bij agileveranderingen. Als coach van coaches, individueleprofessionals en managers, van teams en vanorganisaties. Als trainer van vaak ervarenontwikkelaars, Scrum Masters en Product Owners. Alsfacilitator van workshops aan het begin van en tijdensverandertrajecten. Liefst in een combinatie van dezerollen. Met een stevige basis in de theorie vansoftwareontwikkeling, agile methodes en veranderkundeen met voldoende pragmatiek om de praktijk vanalledag aan te kunnen. Creatief en onorthodox. Altimosstaat voor persoonlijk agile veranderen.

DREAM15 15

Arjen Uittenbogaard

In Scrumprojecten is kennis van werkingsmechanismenmet name belangrijk voor product owners. Zij moetenkunnen omgaan met politiek, conflicterende belangen,partijen die niet goed met elkaar samenwerken en alleswat de wereld complex maakt.

Een terugkerend thema bij jou is ’verhalenvertellen’. Wat maakt verhalen vertellen zobelangrijk voor ons vak?

Als je met requirements bezig bent, gaat het niet in deeerste plaats om het vertellen van verhalen, maar veeleerder om het luisteren naar verhalen en het stimulerendat mensen verhalen vertellen. Ik noem dit storylistening. Je moet goed luisteren naar wat mensenvertellen over hun werk bij het koffieapparaat. Ook alklinkt het als gemopper, daar hoor je de werkelijkeproblemen waar ze mee zitten. Als je iemand officieelgaat interviewen, geef je voor je het weet met je vragenrichting aan het gesprek. Je volgt jouw voorstelling vande werkelijkheid. De geïnterviewde geeft antwoord opjouw vragen, maar je hoort daarmee niet zijn verhaal. Jehoort niet wat hem werkelijk bezighoudt. Ik heb van deweek een workshop gegeven over Clean language. Degedachte bij Clean language is dat je jouwgesprekspartner alleen de woorden teruggeeft die hij zelfheeft gebruikt. Je mag als interviewer niets toevoegen.Het is voor een interview een wat extremegespreksvorm. Maar ik vind het heel belangrijk dat je jeervan bewust bent dat je met jouw interpretaties en jouwwoorden het gedachteproces van de ander danig kuntverstoren.

Als het gaat over het vertellen van verhalen, is hetvoordeel van verhalen dat ze herkenbaar zijn. Deluisteraars hebben vaak hetzelfde of iets vergelijkbaarsmeegemaakt. Ik stimuleer daarom het uitwisselen vanconcrete gebeurtenissen. Bijvoorbeeld iets uit deafgelopen week waar je trots op bent, blij van werd, ofwaar je mee worstelt. Dat zijn vaak heel herkenbaregebeurtenissen. Bij zo’n anekdote kunnen we ons veelmeer voorstellen dan als iemand abstract vertelt wat zijntaken of werkzaamheden de afgelopen week zijngeweest. Juist als je het concreet maakt en vertelt hoemensen momenteel gegevens uit het ene systeemhandmatig moeten overnemen in het andere systeem endat dat dankzij de nieuwe architectuur niet meer hoeft,dan spreek je mensen aan.

Het is ook goed om onderling anekdotes uit te wisselenomdat je zo ervaringen deelt en een gedeeld beeld krijgtvan wat wij ‘goed’ en wat wij ‘slecht’ vinden. Ik kaniedereen aanraden om veel en veel meer gespitst te zijnop het opvangen van dergelijke verhalen en om jeervaringen in een verhalende vorm te delen.

Een andere manier om verhalen te gebruiken isstorytelling. Die kun je gebruiken om patronen ofmechanismen duidelijk te maken of om een veranderingte begeleiden. Een verhaal hoeft dan niet anekdotisch tezijn. Het kan ook metaforisch zijn. Als je dit toepast moetje je realiseren dat storytelling een kunst op zich is. Jemoet eerst op zoek naar een goede metafoor. Het isbelangrijk dat je alles wat je wilt zeggen op een goedemanier in het verhaal kwijt kunt en dat er geen dingen inhet verhaal zitten die er niet mee te maken hebben endus alleen maar afleiden. Het hoeft niet zo simpel te zijndat iedereen meteen weet wie er bedoeld wordt met dekoning uit het verhaal. Het is juist wel goed als daarovereen discussie kan ontstaan. Ten slotte moet je, als je eenverhaal vertelt, daar wel werk van maken. Goed vertellenis ook een kunst. Het moet kloppen. Het moet echt zijn.Op deze manier verhalen vertellen moet je alleen doenals het bij je past, als je het kunt.

Je moet goed luisteren naar watmensen vertellen over hun werk bijhet koffieapparaat. Ook al klinkt het

als gemopper, daar hoor je dewerkelijke problemen waar ze mee

zitten.

DREAMagazine APRIL 201616

Het DREAM event is het enige congres waar ik ieder jaareen gaatje voor vrij houd in mijn agenda. Elk jaar weerkijk ik uit naar een aantal specifieke presentaties, zoalsdie van Ivar Jacobson vorig jaar (die ik eerlijk gezegdtegen vond vallen omdat hij mij niet wist te overtuigenmet zijn promotie van ‘use case 2.0’). Maar dit jaar washet juist het thema waardoor ik deze editie voor geengoud wilde missen: business analyse. Geruime tijd hebik mijn werkzaamheden onder de noemerinformatieanalyse of requirements engineeringuitgevoerd. In 2014 wees een oplettende intermediair mijer op dat de titel business analyse mijn werkzaamhedenveel beter dekte. Sindsdien heb ik mij veel theorie overhet vak business analyse eigen gemaakt en mijnpraktijkervaring verder uitgebreid. Ik was echter zeerbenieuwd hoe vakgenoten de verschuiving van de titelrequirements engineering naar business analyseervaren.

Met de inspirerende en voor sommigen vermoedelijk ookconfronterende keynote van Paul Turner werd hetcongres meteen zeer sterk geopend. Hij verwoordde oprake wijze zaken die mij, en hopelijk ook anderen, sindseen aantal jaren behoorlijk dwars zitten. Ik wil dit graagtoelichten. Allereerst de methodiek die in de ogen vanvelen geldt als de grote verlossing: ’agile’ en/of ’Scrum’.Ik noem beide termen omdat ze maar al te vaak door

elkaar worden gebruikt, zelfs door een grote groepgecertificeerde professionals. Voor alle duidelijkheid: iksta achter de agile principes en pas deze waar mogelijkbewust en onbewust toe. Ik heb echter moeite met deovertuiging dat agile frameworks zoals Scrum eengarantie zijn voor succes. Ik zie namelijk in de praktijkook agile softwaretrajecten met regelmaat mislukken.Bijvoorbeeld door product owners met gebrek aan(product)visie, te weinig betrokkenheid of onvoldoendebevoegdheden om beslissingen te nemen. Gold dat ookniet voor veel gedelegeerde opdrachtgevers bij Prince2projecten? Daarnaast zie ik te vaak teamleden die doorgebrek aan kennis en vaardigheden onmogelijk debeoogde kwaliteit en tempo kunnen waarmaken. Eenmethodiek of framework zorgt uiteindelijk niet voorsucces; dat doen de betrokken en vaardigemedewerkers in en rondom een verandertraject.

Daarnaast valt mij op dat binnen de huidige (agile)werkwijzen de toegevoegde waarde van businessanalyse vaak onderschat wordt en daardoor ook nietvolledig wordt benut. Het vak ‘business analyse’ omvatmeer dan alleen het verzamelen en opstellen van userstories en zelfs meer dan het beschrijven vanrequirements in het kader van softwaretoepassingen. Degemiddelde business analist zal zich met regelmaat ookbezig houden met het beschrijven van processen, hetzichtbaar maken van samenhang (bijvoorbeeld aan dehand van informatiemodellen), of het achterhalen van deoorzaak van een probleem en het uitwerken vanverschillende oplossingsrichtingen. De gemandateerdeopdrachtgever moet besluiten welke veranderingenworden doorgevoerd ter realisatie van de

’Hoe loopt jullie project?Goed hoor! We doen hetnamelijk volgens Scrum’

Het DREAM event van Hidde Nieuwenhuijsen

Ik heb moeite met de overtuiging datagile frameworks zoals Scrum een

garantie zijn voor succes.

door Hidde Nieuwenhuijsen

DREAM15 17

(bedrijfs)doelstellingen. Om te kunnen bepalen wat hetjuiste is, moeten de beslissers inzicht hebben in hetgeheel of in elk geval the bigger picture voor ogenhebben. Het is een van de essentiële taken van debusiness analist om de beslissers dat inzicht teverschaffen. Hiervoor moet de business analist meerinformatie verzamelen en verwerken dan op het eersteoog relevant lijkt. ’Spend money on the right things,before doing things right‘ was in dit kader een van detreffende citaten van Paul waarmee ik mij gesterkt voel inmijn kritische opstelling.

De presentatie ‘De requirements liggen voor het oprapen’van onder andere Louis Veltmeijer en Stefan Staalversterkte mijn streven om processen vaker conform destandaarden en conventies te noteren. Dat schiet er doortijdgebrek regelmatig bij in.

De presentatie van Arjen Uittenbogaard wilde ik, net alsvele anderen, ook deze keer niet missen. Hij deelt zijnmening erg gemakkelijk en op prettige wijze met deaanwezigen. Niet dat ik het altijd met hem eens ben. Ikvind bijvoorbeeld ‘requirements engineering’ wél eenpassende benaming voor bepaalde onderdelen van onsvak en ik ben juist wel blij ’als mijn garage een aantalgoede verbeteringen doorvoert nu mijn auto daar tochstaat‘. Uiteraard in overleg met mij als opdrachtgever.Maar Arjens presentaties staan bij mij tot nu toe garantvoor food for thought en in ieder geval voor een aantalgoede boeksuggesties. Van deze presentatie neem ikzijn tip om ter afwisseling tijdens workshops dissensus inplaats van consensus na te streven, graag direct over.Ook wil ik gehoor geven aan zijn idee om wat vakerverhalen te gebruiken en de skill ‘luisteren naar de ander’niet te verwaarlozen. Wederom een waardevolle enprettige presentatie.

Ik heb uiteraard nog een aantal presentaties bijgewoond.Ook daar heb ik wat van opgestoken hoewel die meminder zijn bijgebleven. Een uitzondering hierop is hetsprintbord van de NS met daarop volgens mij zo’n 60 tenemen ‘hordes’ voordat de eindstreep is bereikt; datplaatje zal ik waarschijnlijk nooit meer vergeten.

Ook dit jaar heeft de deelname aan het congres mij veelopgeleverd; bezinning, bevestiging, kennis, inspiratie,reflectie en gezellige ontmoetingen. Wel hoop ik dat wede oproep van onder andere Paul Turner volgen om onsvakgebied minder laten domineren door agile en Scrumen dat er meer aandacht komt voor deprofessionalisering van de brede lijst van competentiesen instrumenten van de business analist. In dat kader kijkik nu al uit naar de volgende editie van DREAM. Danstaat immers het thema Tooling op de agenda. Ik benbenieuwd of er al gebruiksvriendelijke toepassingen opde markt zijn die de business analist voldoendefaciliteren bij het leveren van toegevoegde waarde voorde organisatie.PS: Voor degenen die meer willen weten over hetonderwerp systeemdenken kan ik het boek’Systeemdenken’ van Bryan, Goodman en Schavelingvan harte aanbevelen.

Het DREAM event van Hidde Nieuwenhuijsen

Ik kijk nu al uit naar de volgendeeditie van DREAM. Dan staat

immers het thema Tooling op deagenda.

DREAMagazine APRIL 201618

1. Paul told the story of the blind men and theelephant, which shows that if you only look atthe parts, you will never see the wholeelephant. Software engineers are highly trainedin systematic thinking. They are used tosplitting up complex problems into smaller, lesscomplex ones. A technique they often use isloose coupling and high cohesion. Are theresimilar techniques that will help us to comefrom a too narrow view on the problem to thebigger picture without making the picture toobig and complex?

A business activity model will provide an overview ofwhat the organisation is about and what are its mostimportant business activities. This model is also basedupon an understanding of the world view which providesthe underlying rationale for the business system.Keeping this world view in mind and developing a BAMon this basis, means that the overview model is focusedon why the business system exists and the analystsknow what needs to be done to achieve this. This modelalso provides a high­level view which gives a context fordecomposition and drilling down into the detail. As analternative, a context diagram also provides an overallcontext for the individual features to be provided within asystem (business or, at a more detailed level, IT) andhelps to identify the full range of actors whose needshave to be satisfied in the solution.

2. Paul did an exercise and asked us duringhis talk to take position between two otherpeople of the audience. We weren’t ablebecause everyone was moving. This was avery good illustration of things that oftenhappen in big IT projects. We have a very clearpicture of the end state, but the way to comethere is nearly impossible. Each systemdepends on other systems which depend on

others and so on. How can System thinkinghelp in those situations?

Again, having an overall view of the underlying rationalefor the business system (its Weltanschauung or worldview) helps to keep all the developments and projects inline with this and focuses attention on what the desiredresults/outcomes are. In addition, the very process ofinvestigating these world views uncovers areas ofagreement and difference between key stakeholderswhich, if not recognized and managed, can derailprojects and programmes.

3. On the same subject. The fact that there isa connection between everything, your projectinfluences other projects, and will be influencedby the other projects as well could lead to aparalyzing effect, trying to control all influencingeffects. Is there a way to avoid or to control thisparalyzing effect. How can you run a successfulproject, being aware of your surroundingswithout being stuck trying to keep track ofeverything around you?

Programme and portfolio management are the key here

Interview

The very process of investigatingthese world views uncovers areas ofagreement and difference between

key stakeholders which, if notrecognized and managed, can derail

projects and programmes.

Agile is in essence adevelopment of systemsthinkingPaul Turner's keynote at DREAM15 was about systems thinking. Hecurrently is retiring from his work at Assist Knowledge Development. Hiscolleague Debra Paul answers some questions we sent her by e­mail.by Geertje Appel

DREAM15 19

– ensuring that individual projects operate within a widercontext of other projects contributing to the same goal(programme management) and are within the overallseries of activities (projects and business­as­usual)undertaken by the organisation. One of the benefits ofprogramme/portfolio management is that the effects ofone project on others is explicitly recognized andmanaged. In addition, programme/portfolio risk, issueand change logs should provide a mechanism to raiseand investigate issues that have a broader impact thanon an individual project. However, systems thinking andthe approaches discussed in earlier responses, providethe overall world view and model that are against whichactions may be benchmarked and checked for continuingalignment with the desired result.

4. Most of our readers are working as arequirements engineer and not really asbusiness analyst. How could they incorporatesystem thinking in their work?

Requirements need context and we have to know WHYstakeholders have requested these requirements andwhat overall business goals they serve. Otherwise, thereis a danger that requirements are identified, documentedand even implemented that do not contribute to theoverall goals of the organisation (or, in extreme cases,are even opposed to them). So, building on the answerto question 1, having an understanding of the consensusworld view and creating an overall BAM/Context diagramhelps requirements engineers to understand the widercontext for their work. We can see this particularly in thedevelopment of a hierarchy of requirements where thebusiness requirements are linked to the overall worldview, objectives, CSFs/KPIs and drive the more detailedfunctional/non­functional requirements.

5. At the moment everybody is moving to agiledevelopment. How does systems thinkingrelates to agile development? What lessonscould the agile community pick up fromsystems thinking?

Agile is in essence a development of systems thinking –the Agile philosophy is based upon holding a particularworld view and the most effective Agile practitionersunderstand this. Further, and in line with the response to

question 1, an overview understanding of the nature anddesired activities of the business system, allows Agilepractitioners to understand priorities, recognize thenature of the increment to be released, ensure there is acohesion to any solution release. One of the dangers onAgile development is that everyone immediately getsconsumed by the detail working out responses toindividual user stories. Allying Agile with systems thinkingensures that the ‘big picture’ is visible at all times andthat the ‘trees’ do not obscure the ‘wood’. A contextdiagram derived from an understanding of the world viewand the activities from the BAM that are beingaddressed, is a great start for an Agile development.Agile is about delivering ‘the right thing’ which would notbe possible without understanding why or what, in thecontext of the wider system of interest.

6. The relation between systems thinking andmental models went a bit quickly, could youexplain the relation between systems thinkingand mental models, or how mental models helpin this process?7. Paul reminded us that communication isreally tricky without a shared mental model. Isuppose a glossary of terms should be at thebasis of a shared mental model. In manyprojects the glossary is a dead or dying. Arethere techniques to make a mental model andto keep it alive?

Mental models are really useful to be able to ‘see’ theholistic view. Too often IT professionals focus onelements of the problem – usually those where IT is the‘answer’ or the users have identified specific problems ­and omit to consider other factors or the root causes. Ifan analyst thinks holistically, a mental model is veryimportant to enable the analyst to perceive how theindividual issues, stakeholders, processes, etc worktogether to create the situation under investigation. Theimportance of a glossary of terms is oftenunderestimated and the process of compiling one forcesBAs/requirements engineers to actually analyse what ismeant by particular terms or concepts; for instance, whatdo we really mean by an apparently simple term such as‘customer’ in this organisation? Creating the contextdiagram referred to above also compels us to think hardabout our stakeholders and whether there are, in fact,actors and user roles that are not obvious from a study ofthe organisation chart.

One of the dangers on Agiledevelopment is that everyone

immediately gets consumed by thedetail working out responses to

individual user stories.

Debra Paul

DREAMagazine APRIL 201620

Veelzijdige keuze aansessies

Het DREAM event van Jan­Willem Zaalberg

Het was als vanouds weer fantastisch, alweer het zesdeDream event. Ik kom er altijd veel bekenden tegen. Heelerg leuk om bij te praten. Het is wat dat betreft net eenreünie. Er zijn veel mensen die ieder jaar komen en datis natuurlijk niet voor niets: die vinden het allemaal eenfantastisch event.

Maar het gaat natuurlijk om de inhoud. Geweldig leukaan het Dream event is dat het de combinatie biedt vantheorie en ervaringen uit de praktijk bij overheid enbedrijfsleven. Ik denk dat het event daarin een uniekepositie heeft ten opzichte van andere congressen op ditvakgebied. Voor ons als werkers in de praktijk is datnatuurlijk heerlijk want wij herkennen de punten waar wijtegenaan lopen in de presentaties en leren van elkaarservaringen.

Naar welke presentaties ben ik allemaal toe geweest? Ikheb een mix gekozen van heel verschillende sessies.Allereerst is er natuurlijk de belangrijkste Keynotespeaker. Daar gaat iedereen naartoe. Het lukt elk jaarweer om een geweldige Keynote speaker binnen tehalen, een bekendheid in de wereld van RequirementsEngineering. Dit keer Paul Turner met een verhaal oversysteemdenken. Een rijk verhaal over inzicht in desamenhang van systemen dat uitnodigt om bewuster tekijken naar de effecten van veranderingen opomliggende systemen.

Dan verplaatsen we ons naar de parallelsessies. Ik bengeïnteresseerd in het inrichten van het requirementsmanagement proces en daarom ben ik gegaan naar eenpresentatie van ABN AMRO samen met Devoteam.Vanuit ABN AMRO werd de context en de behoeftegeschetst en Devoteam vertelde hoe ze tooling hebbeningericht voor die werkomgeving. Interessant was detoepassing van een centrale baseline repository enverschillende project repositories. Daarna ben ik geweestnaar de sessie ‘Agile Requirements Engineering opzichzelf niet meer voldoende’, wat mij erg interesseertomdat je ziet dat er tegenwoordig sterk wordt ingezet opagile werken, meestal met Scrum, maar je merkt dat indat proces op het vlak van requirements management ervaak wat dingen tekort schieten. Carel Daams, depresentator, inventariseert de knelpunten met veelinteractie en discussie met de zaal. Een leuke sessieover een heel relevant onderwerp. Jammer dat ik delezing van Arjen Uittenbogaard ervoor heb moetenmissen want hij is altijd een geweldig verteller met eeninspirerend verhaal.

Daarna was het tijd voor lunch met vakbeurs en dat issuper gezellig. Je komt gewoon tijd tekort want er is

zoveel te zien en zoveelmensen om mee te praten.Fantastisch moment om tenetwerken en folders teverzamelen bij deverschillende stands. Eenaantal stands zorgde voorwat entertainment ennatuurlijk demonstraties.Alleen al om die reden zouje eigenlijk willen dat hetprogramma twee dagenzou duren.

Daarna weer een stelparallelsessies. Wel lastighoor met die parallelsessies want je moet kiezen, je kuntniet alles doen. Nou ja, het beste wat je kunt doen als jeer met een paar collega’s naar toe gaat, is dat je desessies verdeelt en na afloop elkaar bijpraat. Dat is ookwat ik gedaan heb, een vrij lange rit, carpoolen en naafloop delen wat we gezien hebben. 's Middags ben ikgeweest naar de workshop Brainwriting. Erg leuk omeens een workshop te doen. Het bleek een bijzondere,zwijgzame sessie met ideeën opschrijven. Zo komen deideeën van spraakzame en minder spraakzame mensensnel op papier, je kunt er op voortborduren maar zeworden niet doodgediscussieerd. Een prima techniek enleuk om eens mee te oefenen. Daarna ben ik geweestnaar ‘The mistakes Peter made or the value of BusinessAnalysis standards’. Daar was ik natuurlijk wel benieuwdnaar want van fouten kun je leren. De sessie begon meteen verhaal over een beginnend business analist die eenaantal acties doet die op het eerste gezicht prima lijkenmaar toch niet goed uitpakken. Met vervolgens eenanalyse waar dat door komt. Daarna vervolgde de sessiemet een pleidooi voor business analysiscertificeringstrajecten waar de presentator een overzichtvan gaf.

En dan ten slotte de afsluiter, de tweede Keynote. Eenbezinnend verhaal over je bewust zijn van de essentievan de organisatie en de behoeften van de mens daarin,gelardeerd met wijsheden van filosofen en uit hetboeddhisme.

Het was weer een fantastisch programma over hetgeheel. Het Dream event vind ik een uitstekende formulemet goede Keynote speakers aan het begin en het eindevan de dag en een veelzijdige keuze aan sessies vanverschillende bedrijven. Ik heb ervan genoten en als heteven kan kom ik volgend jaar weer. En elk jaar daarnaals het aan mij ligt.

door Jan­Willem Zaalberg

DREAM15 21

Het DREAM event van Jaap­Hein Vruggink

Een DREAM event is wat mij betreft eigenlijk al opvoorhand geslaagd: het is een geweldige gelegenheidom oude bekenden te spreken en om nieuwevakgenoten te leren kennen. Daarnaast is het verfrissendom buiten de dagelijkse praktijk op het requirementsvakte reflecteren.

Ik ben kennelijk niet de enige die er zo over denkt: in zijnaftrap van DREAM 2015 wees Remco Lagarde trots ophet record van ruim 350 deelnemers. En we kregen ookeen inhoudelijk sterke dag. Voor mij ging de dag over debalans tussen groot en klein, tussen zoom in en zoomuit.

Keynote speaker Paul Turner ging met Brits gevoel voorunderstatement in op systeemdenken, denken dat hetgeheel ziet: een business analist moet outside the boxdenken, om de doodeenvoudige reden dat het systeemin zijn geheel sowieso niet in die box past.Paul had een simpele oefening om de aanwezigen eencomplex systeem te laten ‘voelen’. Paul vroeg ons om 2mensen uit het publiek te kiezen en naar de plek middentussen deze twee mensen te gaan. Ik vond het jammerdat Paul direct ingreep: waarom niet 2 minuten chaos omde les in te laten zinken. Dan vergeet je nooit meer hoehet voelt om met zijn allen complex te zijn.Maar wanneer nu het systeem, en wanneer het detail,that’s the question! Paul gebruikte de fabel van de egelen de vos. ‘The fox knows many things, but thehedgehog knows one big thing’. Je hebt verschillendetypes nodig: mensen die als de egel dichtbij heel scherpzien of alles zoals de vos het geheel zien, maar eenbeetje vaag.

Prima theorie, maar hoe doe je dat in de praktijk? Deworkshop door Hans Pettinga en Eelco Herle gaf directhet goede voorbeeld. Zij vertelden hoe ze bij de provincieDrenthe de verschillende projecten rond debasisregistraties aanpakken. En dat doen ze nuchter,stap voor stap. Probeer de problemen in kleine stukjes tehakken. Maar als het nodig is – bijvoorbeeld omweerstand bij stakeholders weg te nemen – dan moet jeniet bang zijn voor holistisch ketendenken.

In de sessie erna citeerde Arjen Uittenbogaard HansPettinga: ’schuivende panelen moet je gewoonaccepteren‘. Arjen wees erop dat dat ’gewoon‘ nietgewoon is. Deze uitspraak tekent de expert op hetgebied van complexe organisaties. Arjen verteldeherkenbare verhalen over weerbarstige patronen incomplexe organisaties en werkingsmechanismen die inje zo’n omgeving kunnen helpen om kleine stapjes in eengewenste richting te zetten. In een complexe wereldmoet je steeds nieuwe wegen zoeken. Hoe?

Bijvoorbeeld door dingen diepijn doen vaker te doen,door het niet te snel metelkaar eens te zijn, door hetconflict te zoeken, doorsubversiviteit te stimulerenen boven alles doorverhalen te vertellen. Arjen is een verhalenverteller, ende kracht van zijn verhaal ga ik juist niet met eensamenvatting weergeven.

En dan nog Arjens keuze in de groot/klein discussie: hetmoet kleiner. Alles moet kleiner. Kleinere user stories inkleinere documenten. De grote systeemview van PaulTurner houden we dan in de gaten via storyboarden, deproduct owner, excursies naar kantoren waar desoftware gebruikt wordt.

In de pauze heb ik gesjoeld bij de Future Group, een IT­collectief dat de admin voor ZZP­ers doet. Goedgescoord, niet gewonnen.

De sessie van Remco Snelders, product owner bijbol.com liep niet helemaal zoals gepland. Remco werdverrast door de enorme opkomst en moest improviseren.Zijn verhaal ging over Specification by example alsmethode om tot shared understanding te komen.Boeiend, maar de door hem voorbereide interactievesessie kwam – buiten zijn schuld­ niet helemaal van degrond.

Sven van der Zee van de Nederlandse Spoorwegensprak over het borgen van requirements bij NS.Bijzonder leerzaam om te horen hoe de NS hier (evenalsvele andere grote organisaties) mee worstelt, enbijzonder moedig om dat hardop te doen. Voor de pijlersMensen en Tools heeft de NS heldere en goedonderbouwde keuzes gemaakt. Op het gebied vanontwikkelprocessen blijkt het lastig om de juisteverhouding tussen groot en klein te vinden. Svennoemde nog de fabel van Phillippe Kruchten over dekikker (alle projecten zijn hetzelfde) en de octopus (alleprojecten zijn anders). Maar dan blijf ik toch liever bij deegel en (vooral) de vos.

Theo Severien sloot de dag filosofisch af. Hij verteldeover essentieel kijken, denken en doen. Daarmee kwamhij in de buurt van startspreker Paul Turner: er issamenhang, we zijn onderdeel van 1 systeem: weesverbonden, wees open, wees eerlijk, wees liefdevol. Naeen tijdje was ik het spoor bijster, maar net toen ik wildeafhaken maakte Theo de verbinding naar de praktijk. Enhij gaf met ’de business rule van het bestaan‘ veel stoftot overpeinzing bij de borrel mee.

Balans tussenzoom in en zoom uitdoor Jaap­Hein Vruggink

DREAMagazine APRIL 201622

Ontdekken

Net gezienDe lol van (ver)dwalen is om onverwacht een prachtige plek teontdekken. En mocht je zelf moeite hebben om zo’n plek te vinden, danzijn er gelukkig altijd mensen die je de goede richting willen wijzen. Datis wat wij met deze rubriek willen doen. Hier zetten we de wegwijzersneer om jullie de plekjes op internet te laten ontdekken waar het goedtoeven is voor de requirements engineer. Deze keer: welkeonderwerpen zien we meerdere keren terugkomen tijdens depresentaties op het DREAM event? Zien we dan de onderwerpen die weactueel vinden in ons vak? Heb je zelf nog mooie plaatsen bezocht dieje wilt delen? Laat het ons weten: dreamagazine@dreamevent.nl.door Johan Oldenziel

Grip op requirementsWe zien dit onderwerp voorkomen in de presentatie vanDevoteam samen met ABN Amro1 en in de presentatievan de NS2. En we kennen dit als de titel van het boekom je voor te bereiden op het IREB­examen. In beidepresentaties ligt de nadruk op het gebruik van tools entechnieken. ABN Amro gebruikt Doors Next Generation.De NS gebruikt een samenspel van Enterprise Architect,JIRA en een Sharepoint­omgeving om de requirementste beheren.

Beter werken met requirementsWe werken al enige jaren met User Stories en willen die

nu verder verbeteren. Dat kunnen we op verschillendemanieren doen:

• door het niveau van een User Story goed te krijgen.Niet te high­level, maar ook niet teveel detail. Hierging de presentatie van het CB (Centraal Boekhuis)samen met QQuest3 op in.

• Door de kwaliteit van de User Story te verbeteren.Garm Lucassen van de Universiteit Utrechtpresenteerde een tool4 om requirements tecontroleren op syntax, semantiek en pragmatischelogica.

• BDD (Behaviour Driven Development) en SBE(specification by example) zien we in zowel depresentatie van KPN/ Sysqa5 als die van BOL.com6.

1http://www.dreamevent.nl/pdf/DREAM15/ABN_AMRO_Devoteam_presentatie_DREAM.pdf

2http://www.dreamevent.nl/pdf/DREAM15/DREAM_NS.pdf

3http://www.dreamevent.nl/pdf/DREAM15/Steur­DREAM.pdf

4http://www.dreamevent.nl/pdf/DREAM15/DREAM15­User_Stories.pdf

5http://www.dreamevent.nl/pdf/DREAM15/BDD_KPN­ITNS.pdf

6http://www.dreamevent.nl/pdf/DREAM15/SpecificationByExample.pdf

DREAM15 23

In een agile­omgeving praat de gebruiker/ product ownerdirect met de bouwer en de tester om tot zowel code alstestcases en daarmee tot acceptatiecriteria te komen.Door ook de bouwer mee te nemen in het opstellen vanacceptatiecriteria (en niet alleen de tester), raakt debouwer meer betrokken en zal zich meerverantwoordelijk voelen om ook de acceptatiecriteria tehalen. En de rol van een requirements­engineer in ditproces?

Waarvoor doen wij het?En we blijven op zoek naar het antwoord op de grotevraag “Waar doen we het voor?”. Hierop komen twee

verschillende antwoorden, die bij nadere beschouwing inde uitwerking toch niet zo verschillend lijken. Paul Turnergaf het antwoord “Hou het geheel in de gaten, benaderhet vanuit het systeemdenken”7. En met systeemdenkenwordt bedoeld om het gehele systeem te zien, dit integenstelling tot de systematische benadering, waarineen probleem in zo klein mogelijke stukjes geknipt wordt.Een verhandeling over wat systeemdenken is in woord8

te vinden en in beeld9.

Theo Severien vertelde met een filosofische benaderingover de essentie10, waarbij ik me weer afvraag wat derelatie tussen ‘het geheel’ en ‘de essentie’ is. Belangrijkhierbij is het transactieprincipe voor menselijkesamenwerking (verzoek – belofte –aantonen–accepteren) vanuit de DEMO­methode11.

Maar ook al denk je aan het systeem, dan zal in de tijddat je aan een oplossing voor (een deel van) hetprobleem werkt, het systeem zelf ook geëvolueerd zijn.Om toch aansluiting te houden, zul je je einddoel alleenmaar bereiken middels kleine stapjes in die richting.

Het Cynefin­framework (genoemd door Daams &Uittenbogaard) kan gebruikt worden om het typeprobleem te identificeren en de bijpassendeanalysetechniek te bepalen. Dave Snowden is degrondlegger van het Cynefin­framework en legt Cynefinuit in een mooie presentatie12.

Heel veel onderwerpen zijn aan bod gekomen, vanpraktisch voor onze dagelijkse werkzaamheden tot meerfilosofische bespiegelingen. Genoeg hersenvoer!

Net gezien

7http://www.dreamevent.nl/pdf/DREAM15/Paul_Turner.pdf

8http://www.thinking.net

9https://www.youtube.com/watch?v=D8ufEeiPoJU

10http://www.dreamevent.nl/pdf/DREAM15/Presentatie_Dream­Theo_Severien.ppsx

11https://nl.wikipedia.org/wiki/DEMO

12https://www.youtube.com/watch?v=y6RfqmTZejU

DREAMagazine APRIL 201624

Donderdag 8 oktober 2015 was het zover: naast deverjaardag van mijn dochter vond het DREAM 15evenement plaats. In 2013 was ik voor het eerst naar hetDREAM evenement geweest. Indertijd had ik enormgenoten van de geweldige sprekers en inspirerendeideeën. Vorig jaar heb ik het evenement aan me voorbijmoeten laten gaan. Zodra begin juli dit jaar denieuwsbrief binnenkwam heb ik me direct ingeschrevenals ‘Early Bird’. De locatie was goed geregeld in hotelVianen, ideaal te bereiken met de auto en volop ruimtevoor de gasten.

De keynote van Paul Turner had als titel ‘SystemsThinking for Business Analysts’. Een van dehoofdonderwerpen was dat wanneer je binnen eenbepaald kader blijft denken, je dan dezelfde resultatenblijft produceren. En met markante visueleonderbouwingen overtuigde Paul Turner de ongeveer300 deelnemers in de zaal New York ervan om hetgrotere geheel te bekijken, om zo een holistisch beeld teverkrijgen. Enkele foto’s gingen overwaterpompsystemen, een handpomp met beperktecapaciteit, een kostbare elektrische pomp met hogecapaciteit, en goedkope met hoge capaciteit, namelijkeen pomp waarbij door rennende kinderen al spelendwater opgepompt werd.

In de koffiepauze erna stonden we met tientallen in eenpaar rijen, om koffie of thee te verkrijgen. Al wachtendrees bij mij de gedachte, dat hier ook Systems Thinkingvan toepassing is. Waarom was het zo geregeld datenkel de vriendelijke personeelsleden van hotel Vianende kopjes mocht inschenken? Het was waarschijnlijkefficiënter om meer kannen neer te zetten, en dedeelnemers zelf hun kopje te laten inschenken. Het

wachten in de rijgaf wel weer degelegenheid omeen spontaanpraatje te maken.

In de ochtend hebik tijdens deparallelle tracks desessie‘Requirementsverzamelen inagile, hoe vermoet je gaan?’gevolgd. Tijdensde sessie bleekdat veel mensener in de praktijk

mee worstelen, datrequirements óf teglobaal zijn(onduidelijk) óf tegedetailleerd (nietde idealeoplossing). Eenantwoord op devraag wat het ‘juisteniveau’ is, kwamniet uit depresentatie. Erwerd uitgelegd datdit afhankelijk isvan de teamledenen het domein. Menhad een formuleuitgewerkt,waarmee van tevoren het ideale niveau van requirements detailleringbepaald kan worden.

De tweede sessie die ik gevolgd heb, werdgepresenteerd door Arjen Uittenbogaard: ‘Zingeving voorRequirements Engineers’. De inhoud was veelpraktijkgerichter dan de titel deed vermoeden. Wat kandeze man buitengewoon spreken, en de visueelgeprojecteerde presentatie was super: géénaantekeningen in woorden, maar foto’s van schilderijenuit de Gouden Eeuw en van Dalí. Zo kwam de‘Kwakzalver’ ter sprake, die op een dag met een middeliemand genezen had, en vervolgens dit middel dag indag uit voor elke kwaal ging voorschrijven. Reflecterendnaar de luisteraars, wanneer een methode of techniekooit heeft gewerkt, wil dat niet zeggen dat een dergelijkeaanpak overal werkt. En Arjen vertelde over zijn mantra‘het moet kleiner’. Over ‘product owners’ die moesten‘ontsplitsen’, omdat de user stories te klein gewordenwaren voor de organisatie. Om het overdraagbaar temaken in de bestaande organisatie, moesten de userstories gebundeld worden. En over het bevorderen vande cognitiviteit, gebruikmakend van de afbeelding vanhet schilderij van Dalí, waarin het hoofd van Lincoln enhet lichaam van de vrouw van Dalí zijn geschilderd.Afhankelijk van de afstand zie je of het een, of het ander.

In de lunchpauze raakte ik in gesprek met eendeelnemer die bij Nedtrain werkt. Het was boeiend omnaar zijn verhaal te luisteren. Het ging over deuitdagingen waar Nedtrain tegen aanloopt, bij hetperiodiek onderhouden van treinen, die afhankelijk vanreisplanningen wisselend door het land ingezet worden,terwijl het aantal onderhoudsplekken beperkt is.

Het DREAM event van Patrick Tangelder

Zomaar met iemand ingesprek gaandoor Patrick Tangelder

DREAM15 25

Tijdens het middagprogramma van de parallelle tracksheb ik de sessie ‘Brainwriting Workshop’ gevolgd. Met‘Brainwriting’ wil men het probleem oplossen dat er ineen groep mensen zijn met het ‘hoogste woord’ enmensen met de ‘beste ideeën’, en dat dit niet dezelfdepersonen hoeven te zijn. Na een introductie van vijfminuten gingen we in groepjes van zes personen aan deslag. De opdracht was om ideeën op papier te schrijvenin zes ronden, van elk 5 minuten. Tijdens de workshopbleek dat er veel ideeën loskwamen, en de meestbijzondere meestal bij ronde 3 en 4. Mijn ervaring wasdat er in een korte tijd door in onze groep, en in anderegroepen, veel ideeën naar boven zijn komen borrelen.

De laatste sessie van de parallelle tracks die ik volgdehad de titel ‘Hergebruik van requirements’. Hier werdeen demonstratie gegeven van de tool Top TeamAnalyst, waarmee aangereikt werd hoe requirementsvanuit een Productieomgeving afgesplitst werden vooreen project (‘branche’). En dat de mogelijkheid bestondom deze requirements na aanpassing door te latenvoeren in een Productie­omgeving (‘merge’). Met dezedemonstratie werd inzichtelijk gemaakt dat gebruikers ensoftware requirements, en diverse modellen vastgelegdkonden worden, en waar ze aan gerelateerd zijn(‘traceability’).

Tijdens de theepauze liep ik wat rondom bij de standjes(de vakbeurs), en kwam in gesprek met een persoonvan CAK. En heb globaal vernomen waar CAK (CentraalAdministratiekantoor) in de praktijk metinformatievoorziening tegenaan loopt als gevolg vanwetswijzigingen, die relatief snel doorgevoerd moetenworden op het gebied van de AWBZ, zorg, uitkeringen,etc.

De afsluiting vond plaats met de keynote sessie‘Verbeteren door het verbinden van (vak)mensen en(ICT)middelen vanuit de essentie door inzicht insamenhang en integratie’ gegeven door Theo Severien.De sessie had een hoog filosofisch gehalte, waarbij‘oude elementen’ uit het leven werden geprojecteerdnaar inzichten voor het vakgebied business analyse. Alsje persoonlijke interesses liggen in het filosofischdenken, dan kon je aansluiting vinden bij zijnpresentatie. Mocht je minder bekend zijn met ‘deessentie’, dan kan het zijn dat de presentatie minderhelder overkwam. Ik vond het in ieder geval eengewaagde rode draad van presenteren, en heb er vangenoten.

Het was voor mij weer aangenaam en inspirerend ommet collega’s de sessies van het DREAM evenement tevolgen. Daarnaast heb ik kunnen bijpraten met ledenvan mijn IIBA studiegroep. En wat ik zelf bijzonder leuken waardevol vond, was om zomaar met iemand ingesprek te gaan en ervaringen uit te wisselen.

Het programma van DREAM 15 was weer top. Deagenda was tot in de puntjes geregeld, en er was volopkeus van interessante sessies. Mijn complimenten aande organisatie van het DREAM event.

Het DREAM event van Katarzyna Kot

Er werd mij gevraagd of ik een kort stukje wilde schrijvenover hoe ik het DREAM event heb ervaren. Ik kan het inéén zin samenvatten: “Het DREAM event anno 2015 iseen groot succes geworden”. Er zijn drie elementen dieop die dag belangrijk voor me zijn:

• Kennis uitbreiden,• Zelf iets kunnen doen, bijvoorbeeld door workshops

te volgen,• En als laatste met vakgenoten van gedachten

wisselen.

Het DREAM evenementgaf me dit jaar weer eenkans om nieuwe kennis opte doen dankzij keynotesen parallelsessies. Het isnet als een batterijopladen. Hetsysteemdenken uitgelegddoor Paul Turner laat meanders over ons vakgebieddenken. Als businessanalist wil ik graag nieuwedingen leren en deervaringen van anderenmobiliseren me om mijneigen werk anders op tepakken.

Dit jaar is het ook gelukt om workshops in hetprogramma in te passen. Deze workshop sessies na delunch hebben gezorgd voor voldoende hands­onoefeningen en leerzame ervaringen. Ik vond het heelmoeilijk om een keuze te maken welke sessie te volgen;voornamelijk bij workshops. Uiteindelijk heb ik voor de“sokkenfabriek” workshop gekozen. Wat een leuke,interactieve sessie! Ik heb nog steeds leukeherinneringen aan hoe we de productielijn moesteninrichten.

Als laatste is het DREAM event voor me ook een soortreünie evenement, waar ik collega's en klanten kanontmoeten. In de loop van het jaar zorgen LinkedIn enandere social media portalen dat ik op de hoogte blijf vanwat mijn collega’s en klanten doen. Maar deze ene keerper jaar kan ik hen allemaal persoonlijk zien. In deinspirerende sfeer van DREAM kunnen we praten en vangedachte wisselen.

De voorbereidingen voor de nieuwe editie van hetDREAM event zijn al in volle gang. Ik kijk uit naarDREAM2016.

Batterijopladendoor Katarzyna Kot

DREAMagazine APRIL 201626

Essentieel kijken, denken, doenIk was voor het DREAM15 event gevraagd om eenverhaal te houden over zelfreflectie. Maken we nuwerkelijk de dingen waar onze opdrachtgevers blij vanworden? Zijn we echt in verbinding met onzestakeholders, of zijn we alleen maar goed in het doenvan een kunstje? Het is een feit dat veel opdrachtgeverszich nog steeds niet echt goed begrepen voelen door deIT. Deze kloof tussen Business en IT bestaat al decennia.Dat duurt echt veel te lang.

Het grappige is dat Paul Turner in zijn openingsspeechmin of meer hetzelfde vertelde als ik. Hij gebruikt alleeneen taal en patronen die voortkomen uit de IT. Mijnboodschap is even concreet als die van hem, alleenvertel ik het in een meer universele taal, een taal die ookwordt begrepen door mensen buiten de IT. Ik baseer mijop mijn ervaringen met mensen uit alle onderdelen vanhet bedrijfsleven en niet alleen specifiek IT. In decommunicatie maak ik graag gebruik van wijsheden enbeelden die zijn geworteld in de oosterse filosofie.Daardoor worden mensen geraakt in hun hart, terwijl hetverstand het nog moet verwerken.

Ik geloof dat we een enorme vooruitgang kunnen boekenals we het westerse wetenschappelijke denken in

verbinding brengen met oosterse wijsheden. Dat is ookwat de Dalai Lama zegt in het boek dat hij daarover in2006 heeft geschreven: ‘Het universum in een enkelatoom’. Het is niet zo dat het oosterse filosofischedenken en westerse wetenschappelijke denken elkaaruitsluiten. Die kunnen elkaar juist versterken. Systemsthinking, waar Paul Turner het in zijn openingsspeechover had, is ook een meer holistische benadering. PaulTurner zegt dat je over de grenzen van je ‘systeem’ heenmoet denken. Je moet systemen zien in hun context.

Mens ­ Business ­ Informatie ­ DataIk kom zelf uit de IT­wereld. In 1979 ben ik begonnen alsleerling programmeur bij het Centraal BureauRijvaardigheidsbewijzen. Uiteindelijk ben ik daar viaCobol programmeur Hoofd organisatie ensysteemontwikkeling geworden. Vanaf 1986 ging ik mijsteeds meer interesseren in de organisatiekant: hoe jevan een bedrijfsplan tot een invulling komt die mensentot op de werkvloer begrijpen. Ik kom dus wel uit de IT,maar heb altijd gekeken naar wat IT­systemen doen voordiegenen voor wie ik ze maak. Menselijke acceptatie washet uitgangspunt.

In 2002 kwam ik in aanraking met de DEMO methodevan Jan Dietz. De DEMO methode gaat ervan uit dat eenorganisatie in de eerste plaats bestaat uit mensen diekunnen beslissen en verantwoordelijkheid nemen. Pasdaarna ga je dat inrichten. Dietz noemt dat inrichtingsvrij.Dat was voor mij een enorme doorbraak, omdat ikdaarmee de mens in samenwerking inzichtelijk kon

Interview

Ik geloof dat we een enormevooruitgang kunnen boeken als we

het westerse wetenschappelijkedenken in verbinding brengen met

oosterse wijsheden.

Een methode heeft eentheoretisch model nodigTheo Severien was keynote spreker op DREAM15. Hij sprak over het uitvier lagen bestaande raamwerk, dat gehanteerd wordt in de methodeDEMO. Naderhand hebben we hem hierover geïnterviewd.Door Reinoud de Leve en Hans Siebering

DREAM15 27

maken en hoe deze dan vervolgens wordt ondersteunddoor systemen. De volgorde is zoals ik ook in mijnpresentatie liet zien: Mens, Business, Informatie, Data. Ikzet daarbij het vakmanschap centraal en dan bedoel ikhet vakmanschap van degene die de meest operationeleprestatie levert. Ik ga dus uit van het meest concreteproduct dat een organisatie levert en bekijk van daaruitwat er nodig is om dat te realiseren.

Presteren door Sociale InteractieIn mijn presentatie liet ik een raamwerk zien dat hetverband toont tussen vier lagen van beschouwen: vanboven naar beneden de sociologische, depsychologische, de mentale en de technologische. In datraamwerk wordt de PSI theorie, Presteren door SocialeInteractie, gepositioneerd in de bovenste 2 lagen. Iknoem die ‘de leer’ van DEMO. In de onderste 2 lagen zithet modelleren in DEMO. Dat zou je ‘het kunstje’ kunnennoemen. De zingeving van een organisatie bevindt zichin de bovenste twee lagen van het raamwerk. Je zietvaak dat mensen veranderingen in een organisatie willenaanbrengen, maar dat dat niet lukt, omdat deveranderingen niet goed zijn verankerd in de bovenstelagen van het raamwerk.

De sociologische laag gaat er over dat eenorganisatie een samenwerking moet willen aangaandie iets positiefs voor alle betrokkenen oplevert. Alsje er als organisatie alleen maar zelf beter van wiltworden dan gaat dat op den duur mis. Dat zag jeonlangs gebeuren bij de banken. Banken waren nietmeer bezig met het leveren van producten waar hunklanten gelukkig van werden.

De psychologische laag gaat over de drijfveren vande mensen binnen de organisatie. Als medewerkersvoornamelijk worden gedreven door angst,bijvoorbeeld omdat ze geen fouten mogen maken,dan wordt het heel moeilijk om dingen te realiseren.Oosters filosofisch denken zoals het boeddhisme

onderscheidt positieve en negatieve drijfveren. Woede,hebzucht en onwetendheid zijn negatieve drijfveren.Samenwerken en creativiteit zijn positieve drijfveren. Zozullen medewerkers in een organisatie zich eerderpositief opstellen als er minder controlemaatregelen(angst voor fouten maken) en meerstimuleringsmaatregelen (meedenken oververbeteringen) zouden zijn.

Ik ga uit van de boeddhistische principes van waarheid,schoonheid, goedheid en liefde. Als je met veelvakkennis iets gedaan hebt waarvan je weet dat het nietwaar is, of als je het niet hebt gedaan met de belangenvan je stakeholders voor ogen, dan kan dat nooit echtiets waardevols opleveren.

De essentieAls ik bij een organisatie binnenkom, bijvoorbeeld bij depolitie of de Marechaussee, dan begin ik volgens heteerder genoemde raamwerk vast te leggen hoe deessentie vorm heeft gekregen. Ik begin bij de mensen diede meest operationele prestatie leveren. Bij de politievraag ik hen bijvoorbeeld om in hun eigen woorden tevertellen wat ze precies doen als er een melding is vaneen ongeval met letsel. Ze vertellen mij dan dat heteerste wat zij doen is ‘ter plaatse gaan’. Dat is eenwerkvloeractiviteit. Later nemen ze misschien ook een

Als je met veel vakkennis ietsgedaan hebt waarvan je weet dat het

niet waar is, of als je het niet hebtgedaan met de belangen van je

stakeholders voor ogen, dan kan datnooit echt iets waardevols

opleveren.

Theo Severien

DREAMagazine APRIL 201628

voertuig in beslag. ‘Voertuig in beslag nemen’ is eenandere werkvloeractiviteit. Uiteindelijk ontstaat er eenmodel van alle werkvloeractiviteiten. Dit model geeftnaast wat ze werkelijk doen vervolgens ook inzicht in depraktische informatiebehoefte. Je kunt bij elkewerkvloeractiviteit vragen welke informatie je voor dieactiviteit nodig hebt.

Vrijwel geen andere methode dan DEMO heeft zo`ntheoretisch model, waar de weergave van de realiteit inpraktische zin snel en in eenvoud zichtbaar kan wordengemaakt. Maar als je verbinding met je stakeholders wiltmaken, als je echt wilt maken waar zij gelukkig vanworden, heb je zo’n essentieel model wel nodig. Demeeste methodes hebben alleen semantische modellen,modellen die beschrijven hoe het systeem er uit moetkomen te zien.

Ik vond het erg leuk om op het DREAM event te spreken.Ik zag veel mensen die met enthousiasme over hun vakvertelden. Ik hoop dat ik jullie een beetje aan het denkenheb gezet, dat jullie je iets meer gaan afvragen inhoeverre je werkelijk in verbinding bent met degenenvoor wie je een systeem ontwikkelt en of je wel altijd kijkt,denkt en handelt uit waarheid, goedheid, schoonheid enliefde.

Interview Theo Severien

DEMO (Design and EngineeringMethodology for Organisations) iseen theoretisch gefundeerde methodevoor het (her)ontwerpen en (her)inrichtenvan organisaties.

De PSI­theorie (Performance inSocial Interaction) neemtcommunicatie als uitgangspunt voor hetbegrijpen van menselijke samenwerking,verbindt die stevig met actie eninformatie, en biedt vervolgens eenorganisatiebegrip dat bevoegdheid,verantwoordelijkheid en competentie vanwerknemers centraal stelt. Hetinrichtingsvrije model dat men met DEMOvan een organisatie maakt, levert ook, enop een objectieve manier, hetleeuwendeel van de requirements voor tebouwen informatiesystemen. ICT isdaarbij een inrichtingstechnologie.

DREAM15 29

Lees alle DREAMagazines op www.dreamevent.nl

DREAMagazine APRIL 201630

Monuta kent zowel een uitvaartbedrijf dat ongeveer15.000 uitvaarten per jaar verzorgt als eenverzekeringsbedrijf met meer dan 1,3 miljoenverzekerden. Als informatieanalisten zijn wij voor beidebedrijven werkzaam om de brug tussen Business en ITte slaan.

Donderdag 8 oktober zijn wij ­ samen met nog tweecollega’s ­ vol verwachting naar Vianen afgereisd omgeïnspireerd te worden door en te leren van deervaringen van vakgenoten. Dit is wat ons betreft goedgelukt.

De keynote ‘Systems thinking for business analysts’ waseen heldere, gestructureerde inleiding tot hetsysteemdenken. De theorie was niet nieuw voor ons, welwas de context waarin het werd geplaatst verhelderend.Als onderdeel van een business analyse traject voor hetuitvaartbedrijf hebben we begin 2015 de ‘Soft SystemsMethodology’ toegepast om met business­vertegenwoordigers op een gestructureerde manier vastte stellen wat we met elkaar verstaan onder het primaireuitvaartproces.

Voor de verzekeringsorganisatie zijn we op dit momentwerkzaam binnen het programma “De Rode Loper”waarin de klantbeleving centraal staat. We zijn onzeorganisatie zo aan het wijzigen dat de klant via deverschillende kanalen (mijn­omgeving, telefonisch,schriftelijk, …) op een consistente en relevante maniernog beter geholpen kan worden. De veranderingen in deprocessen en in de systemen die deze gewijzigdeprocessen moeten ondersteunen worden gerealiseerdbinnen meerdere scrumteams.Met bovenstaande in ons achterhoofd hebben we eenaantal mooie tracks kunnen bezoeken waarin we

geïnspireerd en soms ook bevestigd werden.

Een kort verslag van de tracks die we samen ofindividueel hebben bezocht:

Track De requirements liggen voor hetoprapen in het bedrijfsprocesWe zijn op dit moment intensief bezig met debedrijfsprocessen binnen onze organisatie. Dit was danook een aangewezen track voor ons om te volgen. Detheorie rondom procesmodellering bevestigde ons inonze huidige manier van werken. Dat is altijd prettig. Degestructureerde wijze om vervolgens van processen totrequirements te komen en de toepassing hiervan binneneen Agile omgeving had meerwaarde voor ons enkunnen we toepassen binnen onze werkzaamheden.

Track Zingeving voor RequirementsEngineersOmdat ook binnen Monuta gescrumd wordt was dezesessie voor ons als informatieanalisten erg leerzaam. Degegeven lessen willen we ons dan ook zeker aantrekkenom onze werkwijze verder te verbeteren. Lessen zoals‘het moet kleiner’, niet vooraf één uniforme manier willenbedenken voor alle teams en ’Drijf taakconflicten op despits, maar handel de persoonlijke conflicten af‘. Het isbelangrijk scrumteams op te bouwen met vertrouwen inelkaar zodat het veilig is te kunnen falen (‘safe to fail’)zodat er groei mogelijk is en creativiteit wordtgestimuleerd. Voorwaarde is dat je als team bij elkaarkunt zitten. Arjen sprak over een gekraaktevergaderkamer. Zo hebben wij wel een projectkamermaar had deze onvoldoende bureaus. Om die redenhebben wij wat bureaus ‘geleend’ uit een ander deel vanhet pand om als team bij elkaar te kunnen zitten.

Een aantal mooie tracksHet DREAM event van Erik Jansen en Fred Brandsma

Fred Brandsma Erik Jansen

door Erik Jansen en Fred Brandsma

DREAM15 31

Arjen had zijn tips verpakt in mooie verhalen, daarmeehet belang van het vertellen van verhalen onderstrepend.

Track Specification by Example: methoden,technieken en tools – WorkshopIn deze drukbezochte sessie van bol.com werd openthousiaste wijze een tipje van de sluier opgelicht overhoe binnen bol.com wordt omgegaan met Specificationby Example. Binnen Monuta zijn we op dit moment bezigom de analysefase beter af te stemmen op de sprints;hoe houden we de analyse zo klein als mogelijk zonderin te boeten aan kwaliteit. Dit sluit mooi aan bij devoorbeelden uit deze workshop.De inspectie met de 3 amigo’s (bijvoorbeeld een tester,ontwikkelaar en een materiedeskundige) zien we als eenmooi alternatief voor het v­model waarin de verificatie alseen waterval verloopt.

Track De Sokkenshow – WorkshopLeuke actieve workshop. In de inleiding werdaangegeven dat het van belang is dat de kernwaardenvan de organisatie via ‘heilige woorden’ en daaruitvoortvloeiende leidende principes terugkomen in deprocessen en de organisatie en worden ervaren door demedewerkers en klanten. Wij mochten zelf met dezetheorie aan de gang in een sokkenfabriek. Hier mochtenwe de inrichtingsprincipes in de praktijk waar maken. Hetleidende principe van het groepje waar ik deel vanuitmaakte was ‘In 1 keer goed’. We hebben ons proceshierop ingericht en dit ook kunnen waarmaken. Deleveringen waren in één keer goed. Het aantalgeplaatste orders hebben we echter niet binnen de tijdkunnen afhandelen. Maar ja, dat was ook niet onzeprimaire doelstelling, want beter te laat dan niet in éénkeer goed, tenslotte!

Track Instrumenten uit de UX­praktijk bij hetopstellen van requirementsDeze laatste track van de dag was interessant enleerzaam. De technieken die gebruikt worden in de UX­praktijk kunnen zeker helpen bij het komen tot goedeprocessen.In het programma ‘De Rode Loper’ stellen we de klantcentraal. Om dit ook daadwerkelijk te doen zien we zekervoordelen om de werkwijzen uit de UX­praktijk toe tepassen binnen ons analyse­proces: Geen story zonderscenario, geen scenario zonder klantreis, geen klantreiszonder persona.Bij het verfijnen van de user story’s en de ontwerpenhelpt het de volgende vragen aan onszelf te stellen: Watwil de persona bereiken? Wat kan de persona doen?Hoe wil de persona dat doen?

Wat we geleerd hebben zullen we zeker meenemen inonze dagelijkse praktijk en integreren in onzewerkaanpak. Wij zijn een continu lerende organisatie, enhouden daarmee ons vak levend en levendig.

We kijken dan ook met voldoening terug op het DREAMevent 2015.

Het DREAM event van Michiel Borgart

De ontvangst was gastvrij. Niet alleen dankzij debekende gezichten, maar ook het lekkers bij de koffiedroeg hier zeker aan bij. Dit jaar waren er de meesteinschrijvingen tot nu toe, ongeveer 350. In mijn ogen eenheel mooi aantal voor een evenement als dit en ook voorde locatie, Van der Valk hotel Vianen. Het was eensfeervolle menigte zonder dat het te druk of te vol was.

Ook dit jaar waren alle 3 de BA­certificeringsrichtingenvertegenwoordigd, IIBA, IREB en BCS. Dit laat goed ziendat het DREAM event een breed draagvlak en een grotereikwijdte heeft.

Paul Turner verzorgde de keynote en hij sprak overSystems Thinking for Business Analysts, een disciplineom zaken in hun geheel te bezien en hiermee niet alleennaar de IT facetten van een vraagstuk te kijken. Dit waseen leuke, interactieve sessie met aansprekendeanekdotes. Zijn conclusie was dat je als BA zelf de regiein handen moet houden bij het bepalen waar je naarkijkt.

Ik ben naar vier break­outsessies geweest. Voor mij wasde sessie Gamification door Erik Kuiper het meestverfrissend en vernieuwend. De mogelijkheden, werkingen toegevoegde waarde van het spelelement zijn goeduiteengezet en Erik heeft duidelijke handvatten gebodenvoor de toepassing ervan. Het toevoegen vanGamification aan het instrumentenpalet van een BA is inmijn ogen zeker waardevol en concreet zie ikinteressante mogelijkheden om dit in te zetten bij heteliciteren van requirements.

De afsluitende plenaire sessie heb ik aan me voorbijlaten gaan omdat ik gekozen heb om een rondje langsde stands te maken. Dit was ook heel interessant en ikheb natuurlijk teveel besproken om nu op te noemen. Ikvond het een heel leuke en interessante dag waar ikwederom nieuwe inzichten en contacten heb opgedaanen kijk al uit naar volgend jaar!

Gamificationdoor Michiel Borgart

DREAM15 32DREAMagazineAPRIL 2016Dutch Requirements Engineering And Management

.

Facilitator

PPaarrttnneerrss

Exposanten