LAC 2011, dag 1

LAC 2011, dag 1

Na aankomst in Nieuwegein wilde
ik na een kopje thee eigenlijk even het programma doorbladeren. Blijkt dat mijn
ex collega Egon ook al vroeg aanwezig is. Daar hebben we gebruik van gemaakt
door even flink bij te praten en wat humorvolle herinneringen op te halen. Ook
Jan en Coby nog even gesproken. Niet helaas al die sociale contacten maar
daardoor miste ik wel de ontbijtsessie van Hans Mulder.

Na de introductie door Marc
Ramselaer kwam de keynote op dag 1 van

Ron Rozendaal, CIO VWS. Zijn speech ging
vooral over verschillen. Nl. tussen de (blauwe) architect en de consultant, over
goed genoeg vs. perfect, over ingewikkelde platen vs simpele taal &
versimpelde tekeningen en over het verschil tussen gelijk hebben & gelijk
krijgen.

Het was een leuke opwarmer voor
de dag.

Daarna was Eoin Woods aan de
beurt, leider software architect bij een
bank. Zijn presentatie ging over Principes, viewpoints en perspectieven. Over
strak gedefinieerd beleid en standaarden die applicatie architecten erg
beperkend vinden en niet van toepassing op applicatiearchitectuur. Waarom?
Omdat volgens hem Enterprise architecturen beperkingen opleggen mbt kwesties
die de hele organisatie aangaan, die genegeerd (mogen) worden door software
architecten. Volgens hem komt dat laatste doordat software architecten een
andere

andere scope
en tijdshorizon. En dat liet ie o.a. zien in een matrix. Daarbij gebruikmakend
van de architectuurdefinities van Danny Greefhorst en Erik Proper.

Eigenlijk
het gebruikelijke en beslist niet nieuwe verhaal over niveaus van architectuur
(lagen) over doelen, rationale, leidend en afgeleide principes, over het
besluitvormingsproces, over principes die een gids kunnen zijn en gelukkig
sloot hij af met de constatering dat je samenwerking moet bevorderen en waardes
met elkaar moet delen.

En dan is er een korte pauze.

Aan de hand van het
programmaboekje besluit ik de Agile track te volgen die door Gero Vermaas is
georganiseerd.

Gero start de track door te de
uitkomsten van een onderzoek naar Agile waarin naar voren komt dat organisaties
niet zonder architectuur kunnen. Vervolgens worden de sprekers en de
onderwerpen van hun presentaties opgesomd.

Er zaten 5 presentaties in de track

1e
is van Gero zelf, dan Mark Lankhorst, Vincent Oostindië, Mark van Holsteijn en
vervolgens Freek Leemhuis. Behalve Vincetn voor mij allemaal ‘usual suspects’

Track 1: Gero Vermaas

Agile zorgt
voor een goede communicatie maar omdat het een keten is is het nodig dat de
hele keten Agile is.

Voor de structuur
en ook het proces kan de architect een grote bijdrage leveren.

De architect
communiceert, draagt visie uit en realiseert. Volgens Gero 😉 He thinks big en acts small. Zet het kader
neer en helpt bij het realiseren c.q. blijf
betrokken bij project.

In de realisatie
van projecten moet de architect als technische product owner betrokken zijn Dat
vraagt om dienovereenkomstig vakmanschap en sociale competenties. Daarbij haalt
Gero Conways wet aan: IT is de spiegel van de business unit IT en dat loopt
niet synchroon met inrichting van de businessunit (?) en hij verwijst naar het
boek Simple Architecture van Roger Sessions (waar Mark later nog op terug zal
komen)

Uit het
verhaal begrijp ik in ieder geval dat het ook voor Gero een hele zoektocht is naar
het vraagstuk hoe Agile en Architectuur in balans kunnen komen.

Ook dit
verhaal klinkt natuurlijk bekend. Om niet arrogant te lijken heb ik maar geen
verwijzing naar mijn artikelenreeks over hoe architectuur en Agile samen kunnen
gaan gewezen. Dat doe ik dan maar op deze plek J

Mark Lankhorst zijn insteek
begint met de ‘klassieke’ reden voor agility op business niveau: wendbaar in de
markt, het verdienmodel, het resource en kosten vraagstuk, het kunnen bedienen
vanuit andere kanalen, partnerschap in de keten, compliance met veranderende
regelgeving, volumes (cloud), nieuwe technologie (any device) efficiëntie. Bedrijfsproces
management (in de brede zin) en de Lean gedachten
zijn drijfveren voor agility

Voor elke organisatie kan de
combinatie van drijfveren anders zijn. Flexibiliteit in de bedrijfsvoering is
niet gratis en moet ontworpen worden.

De vraag is wat bereikt moet
worden en wat de impact daarvan is op je bedrijf. Omdat het LAC ook een podium
is voor een beetje reclame voor het bedrijf gaat de presentatie al gauw
richting het nieuwe tool dat een eerste indruk waar de hotspots op risico en
compliance in een bedrijf zitten. Hè getzie, denk ik “Uiteindelijk komt het verhaal
toch weer neer op software en hardware” en waar zitten die 80 Agile practices
dan?

En waar is de mens nou weer gebleven? De
mens is onderwerp van Agile kernwaarde nr. 1 tov de medewerkers gelijk trekken
met infrastructuur en resources. Hmmm, agility als verdien- en marktmodel. Wel
een mooie poging om een ronde staak (Agile) in een vierkant (traditioneel /
geldgefocuste managementmodel) gat te steken.

Het zal wel naïef zijn (en dat
hou ik liever zo) maar de mens is het allerbelangrijkste onderdeel van het
systeem in de definitie van het systeem dat hier gebruikt werd. De dialoog die
ik na de presentatie met Mark startte, werd helaas wreed verstoord. Later kreeg
ik van Mark een kaartspel genaamd ‘het
Agile Service Development Spel” met stories, events en practices, dat zowel
leuk als verhelderend is welke Agile werkwijze je kunt toepassen bij welke
gebeurtenis. Hartstikke bedankt nog vanaf deze plaats!

De lunch is als vanouds meer dan
prima. Die nuttig ik samen met mijn twee (huidige) collega’s Alcedo en Edwin. Al
lopende door de zaal kom ik weer wat oude bekenden tegen en dat nodigt uit voor
klessebessen (ouderwets woord voor netwerken ;))

Middagprogramma:

Vincent Oostindië, volgens die werkt als applicatie
architect bij de Rabobank

focust een project op lokaal
optimalisatie, zonder volledig beeld te hebben van de visie en context en het
leveren van waarde. Daarom kan architectuur projecten
verbinden voor toekomstvaste oplossingen geeft het context en visie en dus waarde
op lange termijn.

Volgens Vincent is de enige die
dit kan, de architect

Agile in architectuur betekent iteratief
met stip op de horizon. Projecten maken kleine stapjes, leren en kunnen bijsturen.
De details kunnen pas ingevuld worden op het moment dat het nodig is met
tegelijk een focus op toevoegen van waarde.

Onder verwijzing naar Martin
Fowler: “If it hurts, do it more often” propageert Vincent: kleine stappen, feedback
en oefenen. Volgens hem moeten architecten vooral het volgende doen:

Bijna dagelijks overleg

Communiceer als architecten
onderling met de teams bij standup meetings, planningssessies en retrospectieven
en over teams heen bij de scrum of scrums meetings.

Definieer technische user stories
is het antwoord op de Agile valkuil (?) bv probeer een aantal alternatieven, dan
kiezen.

Toon technische voortgang
in sprint demo door automatische regressietesten,

doe aan sonar rapportages en
kweek begrip bij alle partijen.

Werk op basis van ‘getting thing
done’ (die is van David Allen) en kanban en prioriteer zichtbaar over projecten
heen,

Houd als doel het wegnemen van
impediments en probeer niet zelf een te worden

Allerbelangrijkste voor hem is de
contante waarde van de investering door Agile: Door direct iets op te leveren
dat verkocht kan worden, genereer je geld om later de aanvulling te betalen.

Zowel op infrastructuur als
project portfolio gebied.

Kan ik het wel mee eens zijn.

Het rare wat mij overkwam bij de
volgende sessie van Mark van Holsteijn’s presentatie is dat ik er geen
aantekeningen van gemaakt heb. Ik heb wel getwittert met reactie over en weer
met Roger Sessions. Ik kreeg ook een beetje kromme tenen omdat het verhaal over
complexiteit reductie zo complex gebracht werd door Mark. Dan kun je het beter simpel
doen. Volgens mij had hij wat voorbeelden uit het boek van Roger Sessions
moeten gebruiken, met vermelding uiteraard. We hebben er later nog even over
gepraat. Marc was echt van mening dat een service oriented architectuur zeer
complex is vanwege de vele ‘verbindingen’ en dat je beter point to point tussen
grotere ( kunt hebben. Dat klonk al wel weer helemaal Roger Sessions. We kwamen
er niet uit. Destijds bij de training op basis van het boek “simple
architecture for complex enterprises” ook al niet. Het gaat er volgens mij nu
juist om dat je geen vaste verbindingen hebt. We gaan ’t er vast nog wel eens
over hebben!!

Als laatste sessie van de track
presenteerde Freek Leemhuis “Agile software development needs a lean approach”

Daarbij meldde hij dat wij zoveel
mogelijk processen en methodes uit de
Japanse krijgskunst moesten leren. Vooral de ontwikkelaars.

Ik kreeg meteen het beeld binnen
van de programmeur met een samoerai zwaard. Zoals Bjorn Aris zei: blijft in het
NU, het NU, het NU. Inwendig moest ik erg lachen waardoor ik natuurlijk een
deel van de presentatie minder aandachtig kon volgen. L

O, ja softwareontwikkelaar maken
meer gebruik van Agile meer dan de business en operations. Zo ik zit er weer in….

Product owner moet mandaat hebben,
weet wat het product moet brengen en zijn tijd goed aan het proces wil besteden.
Die jongens en meisjes zijn moeilijk te vinden.

Scrum is generiek en XP kent meer
engineering technieken.

Lean is de missing link naar de business,
Fabriceren is niet hetzelfde als software ontwikkelen maar heeft meer weg van
productontwikkeling. Vervolgens ontstaat er een discussie BDUF terwijl het
eigenlijk over scenario’s gaat, denk ik… Enfin.

Ik besluit dat ik mijn portie
gehad heb, zeg nog een paar mensen gedag en vertrek naar huis. Het was een
leuke dag. Morgen dag twee.

De presentaties zijn overigens te
downloaden op www.laccongres.nl (het
wachtwoord is LAC11_2311).

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *