Voor de Via Open Space van 22 oktober met als onderwerp agile architectuur willen wij graag het thema Agile Demand uitwerken. Graag wil ik van jullie horen wat jullie ideeen zijn bij dit subthema van agile architectuur. Vandaar dat  ik hoop dat er hieronder een levendige discussie ontstaat.

Wat mij betreft kan dit alle kanten op bewegen, zelf ervaar ik agile software development als een ontwikkeling die vanuit supplyers wordt aangedragen aan klanten, met als belangrijkste reden om uit fixed price constructies weg te komen en project risico's vanuit de supplyers te beperken. Maandag 17 september was er een workshop van Agile Overheid in het DICTU gebouw in Den Haag. Het subthema daar was Agile Contracten. Wat opviel is dat er heel wat partijen zijn die wel heel veel tijd steken in het evangeliseren van Agile. Alsof het de oplossing is voor alles, de enig ware software development methode.

Is de klant er wel klaar voor? Werkt het in alle gevallen? Wat is er aan de kant van de opdrachtgever (Demand side) nodig om Agile tot een succes te maken?

Vragen die in die context bij me opkomen zijn:

  • Is er nog wel sprake van een Demand / Supply verhouding als het gaat om Agile Software Development?
  • Hoe is te borgen dat de Product Owner het juiste mandaat heeft?
  • Is de Product Owner ook de Architectuur Owner, zijn die rollen te verenigen?
  • Hoe ziet een Agile contract er uit?

 

Weergaven: 247

Reactie van Ed van der Winden op 25 September 2012 op 17.21

Hallo Bert,

Ik heb niet op al je vragen antwoord, maar over de derde vraag (Product Owner versus Architectuur Owner) heb ik wel een idee. Dat idee komt voort uit de DEMO training die ik momenteel volg waar het werk van Jan Dietz over Enterprise Ontology aan ten grondslag ligt.

Ik denk dat een Product Owner en een Architectuur Owner per definitie verschillende rollen zijn. De Product Owner heeft een functionele insteek en beschouwt het doelsysteem als een black box. De architect moet het doelsysteem wel zien als een white box en heeft een constructivistische insteek.

Ik was net als jij aanwezig bij de Agile Overheid bijeenkomst, waar gesproken werd over het opleveren van bruikbare producten in elke agile ontwikkelslag. Als analogie werd gesproken over een skateboard, gevolgd door respectievelijk een fiets, een brommer en een auto in volgende ontwikkelslagen. Een belangrijke vraag voor mij is hoe we dit kunnen verenigen met de architectuur insteek: het is duidelijk dat een skateboard, fiets, brommer en auto functioneel gezien steeds een betere oplossing geven (er van uitgaande dat je steeds sneller en comfortabeler van A naar B wilt), maar er is geen enkele reden om aan te nemen dat deze verschillende producten qua constructie en dus qua architectuur steeds een opstapje zijn voor het volgende product. Als voorbeeld: om een fiets te maken heb ik volgens mij niet zo bijster veel aan een skateboard als tussenproduct. En als dat inderdaad zo is, dan heb ik niets aan mijn agile manier van werken.

Tot zover,

Ed

Reactie van Bert Kroek op 6 Oktober 2012 op 10.05

Mooie reactie Ed, ik kan daar wel wat mee. Ik zie een paar lijnen om verder visie langs te ontwikkelen. Ik zal deze even uit elkaar trekken in verschilende reacties waarop er verder kan worden gereageerd.

In deze reactie wil ik even stilstaan bij het concept van Open Space. Dat jij niet op al de vragen antwoord hebt maakt dat de combinatie van vraagstelling en Ed een hele goede toevoeging is voor de Open Space. Bij het Open Space concept gaat het m.i. om het samen de last dragen van het onbekende dat ons tegenhoud om effectief en succesvol te zijn. Vaak hebben we dan te maken met dilemma's: afwegingen die niet absoluut, zwart/wit zijn, maar juist per situatie  leiden tot een andere aanpak. Wat voor jou in de ene situatie werkt hoeft niet zomaar in een andere situatie de beste oplossing te zijn.

De charme van een Open Space zou moeten zijn dat deelnemers kiezen om eens niet in de voor architecten normale patronen stappen van evangeliseren (dit is mijn/de waarheid), oordelen (goed en fout) en oplossingen aandragen.

Het draait juist om het duidelijk krijgen van de vraag, van het probleem. Wat mist er nu, waar komt de moeite nu vandaan. De creatie van een duidelijke context waardoor alle efforts vanaf het moment van die (gezamelijke) creatie zijn te plaatsen en we elkaar bijna niet meer fout kunnen interpreteren, omdat we dat dan ook niet meer willen.

 

Reactie van Bert Kroek op 6 Oktober 2012 op 10.08

Wat helpt het jou in welke situatie om verschil te maken tussen de rollen Product Owner en Architectuur Owner?

Reactie van Bert Kroek op 6 Oktober 2012 op 10.37

Het lijkt me ook zinvol om de genoemde analogie te spiegelen. Er zitten enkele bruikbare aspecten aan die m.i. kunnen helpen om de context te verduidelijken.

Op de door jou aangehaalde bijeenkomst bij Agile Overheid gebeurden verschilende dingen die bij mij wat erg veel weerstand gaven. Om bij de analogie te blijven: Er komt een verkoper bij je te helpen het voor jou beste vervoermiddel aan te schaffen. Jij vertelt hem wat je belangrijk vind en dan zegt de verkoper: Sorry dat ik het moet zeggen, maar jij vraagt hier om een stuur, maar jij wilt helemaal geen stuur, jij wilt een auto! De klant rephrased zijn behoefte en vraagt om een bepaald type auto en krijgt dan als reactie: Sorry, maar jij wilt helemaal geen auto, jij wilt een vervoersmiddel wat je zo snel mogelijk van A naar B brengt. Deze benadering ben ik eerder tegengekomen en brengt de gedachte naar boven: wWe bepaald nu wat ik wil? Ikzelf toch? Niet de verkoper?

Als ik dit op me in laat werken realiseer ik me dat er inderdaad steeds meer sprake is van commodities in de informatievoorziening en dat deze commodities juist zijn gericht op het leveren van componenten, niet op totaalproducten. Ik merk dat mijn perspectief is dat een organisatie zich wil onderscheiden in het samenstellen van haar eigen auto en onderhandelt we over de prijs, kwaliteit en inruilwaarde van componenten.

Reactie van Atilla Vigh op 22 Oktober 2012 op 14.27

Volgens mij gaat de Open Space over Agile Architectuur en dat gaat verder dan alleen Software ontwikkeling. Architectuur behelst meer dan de software, ook hardware en alles wat daarbij komt kijken. En nee de Cloud gaat je niet met alles helpen (lees mijn stukje bij subitem 2 van deze Open Space).

Ik denk juist dat dit subdeel een van de belangrijkste krachten kan zijn voor het onder architectuur ontwikkelen van ICT oplossingen, doordat je veel dichter op elkaar zit qua ontwikkeling en ideeen uitwisseling. Dus zowel de eindklant als alle leveranciers zitten in een hok en zullen dan wel transparant naar elkaar moeten zijn. Als de insteek van de opdrachtgevers kosten drukken is en die insteek van de leverancier meerwerk, dan zal geen enkele methode werken. Dat zal heel duidelijk gemaakt moeten worden naar beide partijen. Laat dan een onafhankelijke derde het Agile proces leiden (die heeft geen belang bij beide kampen). En zolang ze zich als kampen opstellen, vraag ik mij af of er wel sprake van samenwerking is.

Reactie van Bert Kroek op 22 Oktober 2012 op 16.00

Dag Atilla,

ik zie je schrijven dat transparantie en een gezamelijk belang voorwaardelijk zijn om de kracht van Onder Architectuur Ontwikkelen van ICT oplossingen uit te kunnen nutten. Het klinkt alsof je aangeeft dat Agile juist dan kan werken.

Is dat wat jou betreft ook contractueel te borgen?

Reactie van Atilla Vigh op 22 Oktober 2012 op 16.10

@Bert,

Het zal lastig worden omdat contractueel te borgen. Je kan op papier zoveel mogelijk proberen vast te leggen en te juridificeren, maar als een van beide kanten er eigenlijk geen zin in heeft, moet je er volgens mij niet aan beginnen.

Transparantie werkt voor mij alleen maar als er daadwerkelijk van beide kanten intrinsiek belangstelling is om naar en zo'n optimaal mogelijk resultaat te komen. Helaas heeft transparantie natuurlijk een aantal nadelen: openheid van zaken zou wel eens een competentieprobleem zichtbaar maken, of het begin van een organisatiewijziging inluiden. Dus er ontstaat een belangenafweging, wat overigens heel natuurlijk is. De vraag rijst hoe je die belangenafweging zodanig kan beinvloeden, opdat er een veel lagere dreiging vanuit gaat. Overigens als er eigenlijk al lang bekend is in de markt, wat de oplossing is voor een probleem (zonder uberhaupt aan architectuur te doen), maar iedereen weet dat een positie of meerdere posities in gevaar dreigen te komen, kun je beter wachten totdat dat probleem in die specifieke organisatie beslecht is (zonde van je tijd)

Opmerking

Je moet lid zijn van Via Nova Architectura om reacties te kunnen toevoegen!

Wordt lid van Via Nova Architectura

Sponsoren

Advertenties

Je kunt hier adverteren

© 2019   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden