De Via Open Space van 22 oktober staat in het teken van Agile Architectuur. Een van de dimensies hierin is de dimensie agile organisatie. Ik hoop hier een discussie te starten over dit onderwerp en te zien of we kunnen komen tot een of meer interessante vragen voor de sessie van 22 oktober.

Principes uit het Agile Manifesto met betrekking tot organisatie zijn onder andere:     

  • Mensen uit de business en ontwikkelaars moeten dagelijks samenwerken gedurende het gehele project.
  • Bouw projecten rond gemotiveerde individuen. Geef hen de omgeving en ondersteuning die ze nodig hebben en vertrouw erop dat ze de klus klaren.
  • De meest efficiënte en effectieve manier om informatie te delen in en met een ontwikkelteam is door met elkaar te praten.
  • De beste architecturen, eisen en ontwerpen komen voort uit zelfsturende teams.
  • Op vaste tijden, onderzoekt het team hoe het effectiever kan worden en past vervolgens zijn gedrag daarop aan.

Duidelijk is dat rechtstreekse interactie met elkaar een heel belangrijk aspect is. Maar ook verantwoordelijkheid geven en nemen en vertrouwen op elkaars bijdrage. Ik wijs er regelmatig op dat we moeten bewegen van architectuur als aparte functie binnen de organisatie naar architectuur als vaardigheid van de organisatie. Dat past prima binnen deze Agile principes. Organisaties moeten een manier van samenwerken vinden waarin de zaken waar architectuur voor staat een integraal onderdeel worden van keuzes maken en beslissingen nemen. En de architect kan dat faciliteren en begeleiden. De grote vraag is natuurlijk ‘hoe kom je daar?’. Wat houdt ons tegen om op deze wijze te werken? En is het vanuit architectuuroogpunt bezien realistisch of dromen we eigenlijk van een in de praktijk onbereikbare utopie? Ik ben heel benieuwd naar concrete praktijkervaringen. En waar je dan tegenaan loopt. Zelf denk ik dat de sleutel voor een groot gedeelte ligt bij een zuivere verdeling van verantwoordelijkheden. Als we denken in verantwoordelijkheden in plaats van taken, komen we al een heel eind.

 

Weergaven: 357

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

Hallo Marlies,

Ik ben het met je eens dat de introductie van Agile werken veel te maken heeft met verantwoordelijkheden. Jij spreekt daarbij over verdeling van verantwoordelijkheid. Maar is het bij een agile aanpak juist niet zo dat elk teamlid verantwoordelijk is voor het totaal? En dat betekent voor vrijwel iedereen dat je ook bepaalde "verworven rechten" op zult moeten geven. Als agile architect zul je zowel meer met je voeten in de modder moeten staan temidden van de ontwikkelaars en beheerders, maar ook meer moeten afstemmen op managementniveau. En de beleidsmakers en managers zullen ook bereid moeten zijn om (gedelegeerd) mee te draaien in het team - denk aan de product owner die namens de eigenaar van moment tot moment beslissingen moet kunnen nemen.

Als antwoord op je vraag "Hoe komen we daar?" zou ik als architect die de agile manier van werken een warm hart toedraagt, geneigd zijn om als eerste tijd en moeite te stoppen in het "meekrijgen" van de betrokken managers. En tegelijkertijd zelf het goede voorbeeld geven door zeker niet los van de uitvoerders te werken. Een moeilijke balans omdat je als architect je tijd en aandacht tussen twee heel verschillende kanten van de organisatie zult moeten verdelen.

Ed

Reactie van Marlies van Steenbergen op 26 September 2012 op 7.22

Hallo Ed,

Ik ben het helemaal met je eens. Dat elk teamlid verantwoordelijk is voor het totaal is helemaal juist. Maar dat betekent in mijn ogen ook dat de architect niet als enige verantwoordelijk is voor de samenhang tussen oplossingen. Het management heeft daar ook een grote verantwoordelijkheid in. En dat laatste zie ik nog best vaak ontbreken. Ik vind het een heel boeiende vraag hoe dat om te buigen. Ik denk dat het te maken heeft met als architect zinnige dingen zeggen en doen en zo een 'trusted partner' te worden van het management. En dan ook nog waar te maken wat je zegt. Ook dat hoor ik nog vrij vaak: "mooie verhalen, maar wat nu?".

Marlies

Reactie van Atilla Vigh op 16 Oktober 2012 op 12.51

Hoi Marlies en anderen,

Heel goed plan om in korte sessies zowel domeinspecialisten ("mensen uit de business": dat is ook een van onze (ICT-ers) problemen!) als ICT-ers gezamenlijk naar een specifiek doel te laten werken. Edoch, dan zal er eerst een grote stap genomen moeten worden door - in mijn optiek de ICT-ers - dat is "ons taalgebruik en manier van doen". Financieel experts, HRM-ers (de collega's die werken bij andere ondersteunende afdelingen in veel bedrijven en instellingen), maar ook  geologen (bij Shelll), hypotheekdeskundigen (bij banken), technisch tekenaar (bij een bouwonderneming) (de primaire procesdeskundigen, daar waar het allemaal om gaat!!!!!!) hebben een heel andere denk- en leefwereld dan wij ICT-ers. Wij (ICT-ers) zullen pas "in gesprek" komen met "die anderen" en voor "vol worden aangezien" als we "de taal van hen spreken" en "het bijbehorende gedrag van hen omarmen"'. Overigens ben ik echt van mening dat wij niet de enige zijn die daar last van hebben: "die andere collega's van ondersteunende afdelingen, als finance, HRM (dus die zich niet bezighouden met het primaire bedrijfsproces)" hebben hetzelfde taal- en cultuurprobleem. Iedereen kent de IT-inkoper wel, en nou ga ik charcheren: "afgestompte botte boer, die alleen op prijs kijkt en ICT-projecten en resources inkoopt alsof het potloden, stoelen en tafels zijn" :-) Zie hier de reden van de grote afkeer die "dit soort types" opwekken.

Dus onze eerste opdracht - als het gaat om de Agille organisatie - is het heel goed opbouwen van relaties met "die anderen", waarbij taal en cultuur een voorname rol heeft. 

Reactie van Marlies van Steenbergen op 18 Oktober 2012 op 8.47

Hallo Atilla,

Met je laatste alinea ben ik het helemaal eens. Het gaat om het opbouwen van goede relaties en daar zijn taal en cultuur essentieel in. En bij het opbouwen van relaties werkt het niet om in je eigen wereldje te blijven hangen. Het gaat mijns inziens om het gezamenlijk richten op waar het eigenlijk om gaat (en dat heeft alles te maken met taal en cultuur). Wat is belangrijk voor de organisatie, en wat draagt architectuur/de architect daaraan bij. En hoe organiseer je dat dan. Terug naar de essentie. Als je dat helder hebt, kun je het ook bespreekbaar maken.

Reactie van Ed van der Winden op 18 Oktober 2012 op 12.59

Hallo Atilla,

Ik ben het helemaal eens met wat je aangeeft. Toch schuilt er volgens mij een gevaar in omdat het niet volledig is. We bevestigen als architecten vaak dit beeld naar elkaar, het beeld dat we meer de taal van onze klant moeten spreken, minder in ivoren torens moeten zitten en vooral niet te ingewikkeld doen naar mensen die uit een ander vakgebied komen. Helemaal waar.

Maar... ik vind dat hetzelfde ook geldt voor de mensen in andere rollen richting ons als architecten. Ik ben ervan overtuigd dat wij als architecten vaak belangrijk werk doen en veel toegevoegde waarde voor een organisatie kunnen leveren. Is het dan te veel gevraagd dat men ook een beetje naar ons toebeweegt, probeert mee te gaan in onze manier van denken? Natuurlijk moeten we dit zo laagdrempelig mogelijk maken, maar het werk wat wij doen is tenslotte wel in het belang van die andere partij. Die zou zich wat moeite moeten getroosen omdat hij beseft dat het voor hemzelf van belang is.

Het gevaar van een te eenzijdige benadering is dat we als architecten te makkelijk buiten spel worden gezet. Als het spannend wordt, kan men altijd het argument gebruiken dat "de architect zijn verhaal niet duidelijk genoeg vertelde" en daarmee wordt een advies (dat wellicht veel waarde had kunnen hebben) van tafel geveegd. Communicatie, elkaar begrijpen, zal altijd een taak van beide partijen moeten zijn. Ik zal altijd mijn uiterste best doen om zoveel mogelijk naar de andere partij toe te bewegen, maar ik verwacht van die andere partij dezelfde houding naar mij toe. Ik persoonlijk, maar ook wij architecten als groep, kunnen dit niet alleen!

Ed

Reactie van Atilla Vigh op 18 Oktober 2012 op 13.16

Helemaal mee eens Ed, het is twee richtingen verkeer (zoals elke dialoog van nature is). En (wilde weer maar zeggen :-)) in deze tijden van kortetermijndenken ("gezien de crisis") zal het het uiterste van onze vergen, want daar waar veelal collega's direct werkzaam in de primaire bedrijfsprocessen van onze organisaties (of klanten van onze organisaties) direct besparingen of meer omzet kunnen creeeren met nieuwe ideeen, is het voor ons "architecten" een stuk lastiger om aan te geven dat bepaalde veranderingen in het primaire bedrijfsprocessen landschap, andere manier van organisatie inrichting of het gebruik van slimme technieken in de ICT, eenzelfde omzetverhoging of kostenbesparing kan opleveren.

Misschien een idee, om die "andere ondersteuners (finance mensen, HRM mensen)" te betrekken in de Agile architectuur processen en laten we gelijk een prijsvraag uitschrijven voor een betere (lees pakkende) naam voor dergelijke trajecten, zodat iedereen (alle medewerkers van een organisatie of instelling) zich herkennen.

Reactie van maikel.mardjan op 18 Oktober 2012 op 22.35

"De beste architecturen, eisen en ontwerpen komen voort uit zelfsturende teams." Ik ben benieuwd wat de ervaringen zijn van de deelnemers aan deze open space in scrum trajecten waar kort cyclus code wordt ontwikkeld. Welk type architecten zijn nog nodig of noodzakelijk in scrum teams?

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