IT is tegenwoordig een belangrijk middel, zo niet het belangrijkste middel, om innovatie te realiseren en het verschil te maken met de concurrentie.

Source: www.managersonline.nl

De beweging binnen IT naar agile is reeds lang gaande — ikzelf ben daar sinds 1995 bij betrokken. Het artikel stipt een aantal interessante punten aan in deze beweging:

1. De "business" heeft deze beweging nog niet ingezet, en denkt nog in silo's en in beton gegoten processen
2. IT wordt (teveel) gezien als een (interne) leverancier, opgesloten in de eveneens traditioneel ingerichte relatie tussen opdrachtgever/nemer (vraag-, en aanbod)
3. IT wordt teveel gedwongen in beheer en onderhoud waardoor het niet betrokken kan zijn bij innovatie en veranderkracht (co-creatie, of gezamenlijk optrekken ontbreekt)
4. Er ontbreekt structuur, niet alleen aan de business kant, maar ook aan de IT kant, of IT al naar agile is gegaan (of soms juist dan) of niet

Veel agile veranderinitiatieven, zoals bijvoorbeeld bij de ING bank, zijn met ontzettend veel enthousiasme en initieel succes van start gegaan. DevOps, hackathons, zelfsturing hebben veel in beweging weten te brengen in heel korte tijd. Hoe schaalbaar de resultaten in werkelijkheid en op de langere duur zijn valt nog moeilijk te zeggen maar er zijn wel degelijk allerlei signalen waaruit we kunnen opmaken dat daar problemen opdoemen. Veel agile projecten pochen over het niet meer nodig zijn van documentatie, modellen en architectuur. Dat lijkt toch niet helemaal op te gaan.

We richten schaalbare varianten in van scrum, maar toch lopen we tegen allerlei problemen aan die door aanhangers van de meer traditionele methodes worden aangegrepen om hun gelijk te halen: zie je wel, we kunnen echt niet zonder architectuur.

Ik denk dat we inderdaad niet zonder architectuur kunnen, of modellen, of documentatie. Alleen ben ik er van overtuigd dat dit heel andere architectuur, modellen en documentatie zijn dan in die traditionele aanpak en zoals ik die door de meeste architecten zie produceren. De aard van de artefacten is anders, het proces waarmee ze tot stand komen is anders, en hoe ze gebruikt worden is anders. We weten dat we nooit geweld moeten doen aan de principes van agile zoals in het manifesto genoemd. Maar het plaatsen van mensen boven processen wil nog niet zeggen dat we aan het laatste géén aandacht moeten schenken!

In schaalbaar agile speelt architectuur juist een heel belangrijke rol. Maar wel wezenlijk anders ingericht dan we misschien gewend waren als architecten.

Or: don't use the architecture Decision Log as a control mechanism.

Tempting isn't it? All those architecture decisions get logged there. Favourite pastime of the control-freak enterprise architect: review the logged items and write comments on them, reset their state from accepted to rejected.

Don't. Well, let them log. Let them review. Let them improve. But don't interfere unless absolutely necessary. And with necessary I usually mean: you have something to bring to the table that will actually help the logger to learn, to improve their future decisions. And remember you are the last one in the chain of reviewers - or should be if you have your architecture process operating maturely.

My preferred strategy for the Decision Log is to use it, not as an extra governance tool so much (although it is a crucial part of the governance framework), but more as a learning tool.

The learning aspects are:

• The need to make architectural decisions explicit. Think what you are actually doing. Write it down so that someone else (and you, possibly, two months from now) can understand it.
• Review decisions from your team-mate. Understand, discuss, improve.
• Review decisions from other teams: what are they doing over there? Can we re-use some of it? Is there an overlap?

It may very well be that you see valid improvement points. But unless those really create large enough problems, it is often better just to let them be, and let the loggers discover for themselves what the improvement points are, than to interfere and order rework done. This way the process becomes a learning journey, where the net improvement over longer periods of time (say, years) is much higher than when you constantly give in to micro-governance.

Sustainable architectural velocity is what you should aim for.

Niet alleen in Nederland maar wereldwijd is er een ontwikkeling gaande in de relatie tussen werknemers en bedrijven. We zien dit op een aantal aspecten. We zijn aan het kantelen.

Ten eerste in het toenemende aantal zzp'ers (of ZP'er, Zelfstandige Professional, zoals ze zich vaak liever noemen). In 1996 waren er nog 330 duizend personen werkzaam als zzp’er, inmiddels zijn dat er ruim 800 duizend (2014) (bron: CBS). Er is veel discussie over de oorzaak van deze toename. Sommigen zeggen dat de slechte economische omstandigheden die veel bedrijven dwongen personeel te ontslaan hiervan de oorzaak zijn. Deze mensen zijn vaak niet vrijwillig zzp'er geworden, en dan ook nog vaak voor veel lagere kosten weer aan het werk gegaan voor hun oude werkgever.

Anderen zien de oorzaak in het feit dat mensen veel meer dan vroeger behoefte hebben aan zelfstandigheid, eigen keuzes kunnen maken, en meer invloed willen hebben op hun werk. Hoe het ook zij, in werkelijkheid zal er niet sprake zijn van één enkele oorzaak maar is er veeleer een complex krachtenveld dat dit proces in gang zet.

Ten tweede zijn veel mensen, velen daarvan inderdaad de zp'er, zich op een nieuwe manier aan het organiseren. Mede dankzij ontwikkelingen in communicatietechnologie is ieder individu op elk moment en op elke plaats in staat toegang te krijgen tot alle kanalen waar hij behoefte aan heeft om zijn werk te doen. Of dit nu informatie is van het internet, of via contact met collega's of vakbroeders, feit is dat niemand meer zijn werk hoeft te doen op basis van elders ontwikkelde en gestandaardiseerde werkinstructies, ontstaan en ontwikkeld in een tijd dat die alomtegenwoordige communicatiemiddelen nog niet aanwezig waren (zie mijn artikel De dood van de postbode).

Hierdoor ontstaat de mogelijkheid veel meer ad-hoc te werken, de beste strategieën om een oplossing te realiseren gaandeweg te ontwikkelen, kortom meer agile te kunnen produceren.

In dat proces heroriënteren organisaties zich op dat terrein van aansturen en regelen. De werkvloer is bezig zichzelf op een andere manier te herorganiseren, dwars door de organisatie (en óver organisaties!) heen. Er ontstaan allerlei netwerken, uit noodzaak of gewoon om het eens uit te proberen, buiten en naast de hiërarchische structuur die de organisatie de werknemers traditioneel aanbiedt. De potentie van die nieuwe netwerken uitbaten is vaak niet makkelijk omdat de organisatiestructuur maar vooral de organisatiecultuur dit niet toestaat.

In de Tegenlicht uitzending Nederland Kantelt wordt duidelijk gemaakt dat deze beweging niet meer een "beweging" is maar voor elke organisatie onontkoombaar is, willen ze overleven in een wereld die overal aan het kantelen is. De uitzending bevat een groot aantal voorbeelden van kantelende organisaties, en het bijzondere is dat ze zich niet beperken tot een bepaald segment van de maatschappij of alleen maar hoog opgeleide professionals betreft:

1. Een thuiszorg organisatie
2. Een ministerie
3. Een aannemersbedrijf
4. Een politieregio
5. Een schoonmaakbedrijf

Vaak is in de board room op RvB of RvC niveau het bewustzijn van die noodzaak wel aanwezig, of begint dat door te dringen. Maar tevens leeft er wanhoop of zelfs paniek (zoals Jan Rotmans het formuleert) over het vermogen van de eigen organisatie om die verandering te kunnen realiseren.

Enterprise architectuur to the rescue.

Maar dan wel enterprise architectuur "een beetje anders".

Vaak is enterprise architectuur in het verleden ingezet voor grote verandertrajecten, top-down geïnitieerd, en ingebed in een veeljarenprogramma. Voorbeelden van organisaties die dat op die manier inzetten zijn Ziggo, ABN-AMRO en anderen. Dat gaat niet werken bij een kanteldoelstelling. Immers, een kantelende organisatie zal moeten wennen, en vaak snel ook, aan het werken vanuit de basis. Niet vanuit een aansturend kostbaar programma. Werken vanuit de basis wil echter niet zeggen "zomaar wat doen". De samenhang, de cohesie in de inspanningen is zo mogelijk nog belangrijker bij het realiseren van een kanteling, en bij het opereren naderhand als gekantelde organisatie. Je zou zelfs kunnen zeggen dat een gekantelde organisatie voortdurend in een veranderproces zit, een veranderprogramma als je wilt. Maar dan één die niet op het tekenbord is ontstaan, maar die voortdurend ontstaat, een continue creatie.

Hoe breng je die cohesie tot stand? Belangrijker nog: hoe houdt je dat vast gedurende het proces? En hoe doe je dat vanuit de basis, in tegenstelling tot veel enterprise architectuur trajecten zoals ik die ken die vanuit een soort command-and-control positie opereren? We willen immers juist niet een organisatie, een afdeling, een proces, ontwerpen in isolatie en dat dan vervolgens implementeren in de werkelijke wereld. We willen niet standaarden en kaders bedenken, omdat het een goed idee lijkt of misschien zelfs onontkoombaar, los van de mensen die ermee moeten werken.

Voor enterprise architecten is het werken met roadmaps, die een current state transformeren in een target state, een meestal toegepaste werkwijze, aansluitend op een vertrouwde manier van denken. Op die roadmap worden een aantal elementen geplot, die building blocks worden genoemd, te onderscheiden in architectuur building blocks (die vaak non-functionele kwaliteitskenmerken beschrijven) en solution building blocks (die de daadwerkelijke stappen uitvoeren, conformerend aan de architectuur building blocks). Dit is een erg deterministische, bijna fabrieksmatige manier van denken. Het laat weinig ruimte aan het proces zelf, dat immers volgend moet zijn ten opzichte van het plan.

Wat enterprise architectuur echter ondertussen ook doet is veel interessanter. Er worden door architecten namelijk een aantal modellen gemaakt die weerspiegelen wat die current state eigenlijk is (en die target state, maar dat is in agile enterprise architectuur minder interessant, hierover later meer). Die modellen geven allerlei doorsnedes in de organisatie. Er worden bijvoorbeeld value chain diagrammen gemaakt, die expliciteren op welke wijze de organisatie toegevoegde waarde levert voor zijn stakeholders (in principe de klanten, maar daaronder worden ook vaak aandeelhouders geschaard). Die modellen geven inzicht in de organisatie, in wat het doet en hoe het dat doet. Met andere woorden: die modellen creëren transparantie. En laat dat nu net datgene zijn waar de grootste behoefte aan is bij kantelprocessen of holocratie/sociocratie transformaties!

Het verschil is echter dat wij deze modellen niet gebruiken om kwaliteit te garanderen (de maakbare organisatie) maar meer om inzicht te krijgen in "emerging quality", kwaliteit die a.h.w. ontstaat door de veel effectievere processen in gekantelde organisaties.

Die gereedschapskist van de enterprise architect is echter een tweesnijdend zwaard. Teveel focus op de modellen en het zicht op datgene wat wordt gemodelleerd (nl. de organisatie en de mensen) raakt ondergesneeuwd. Wat we ons dienen te realiseren, als "gekantelde" enterprise architecten, is dat onze modellen een weerspiegeling zijn, die in staat moet zijn real-time te laten zien hoe het er voor staat. De modellen zijn voortdurend in flux. Om dat te bewerkstelligen moeten we die modellen koppelen met real-time indicatoren, sensoren als je wilt, in de organisatie. Je weet immers niet wat er op welke plek in het complexe systeem van de zelfsturende organisatie gebeurd, maar je wilt het wél weten áls het gebeurt teneinde dat te laten weerspiegelen in de modellen.

Hier zien wij een grote rol toebedeeld aan moderne communicatietechnologieën, die ons in staat stellen het zenuwcentrum van de organisatie te benutten om dat spiegelbeeld te maken en in sync te houden. Het schijnt dat wij in onze hersenen ook een soort spiegelmodel van ons lichaam in stand houden. En dat wij voortdurend dat model gebruiken om het aan te houden tegen allerlei what-if scenario's om ons gedrag te sturen. Dat houdt in dat wij een model hebben van onszelf en onze omgeving, tegelijkertijd, en dat wij dat niet alleen hebben voor het huidige moment (de real-time weerspiegeling) maar ook voor een reeks van mogelijke toekomstpaden. We modelleren dus niet echt meer een target state, maar een hele reeks van tentatieve target states, die meer of minder ver in de toekomst liggen. En die wij niet meer gebruiken om onze organisatie te sturen (want dat is immers een onvoorspelbaar proces geworden) maar om de bewegingen die plaatsvinden te helpen optimaliseren. De organisatie is out-of-control, maar in-sync!

Dat is waar enterprise architectuur werkt in gekantelde organisaties, of organisaties die bezig zijn met dat proces.

Everyone in the agile community will understand this (I expect ?).

If we talk about "managing" we agilists understand that the team "manages" itself. That difference with "traditional" projects, managed by a project leader or -manager, is constantly emphasised by scrum pundits.

This article is not for that in-crowd but for people attempting to understand the agile approach to projects. There is no difference in opinion as to why we have projects: we want to deliver maximum value to the business in a controlled environment. The boundary conditions are also not debated: we are limited in resources, usually categorised as money and time. A big difference however is already present in the definition of "value".

In "traditional" approaches rigorous attempts are made to define "value", almost to mathematical precision. Only after we achieve shared (that is, shared between the business and the delivery vehicle: the project) understanding of what is meant by "value" can we start work on delivering that value.

For an agile project we choose a different approach, one that is believed to be overall much more effective in two aspects:

• total value delivered over the same time
• the quality of that value in terms of maintainability, usability (or fit-for-purpose) and other non-functional quality attributes

In agile projects we may have a shared understanding of "value" between business and project, but that understanding is much more vague and only present as a general sketch. It is only through time, as the project progresses, that parts of that functionality are made explicit. Those parts are always "small", that is: small enough to be completed in one sprint, usually a two-week time period. And these bite-sized portions of functionality are placed in what is called the sprint-backlog.

The difference with the more traditional approach becomes clearer: the total value delivered by the project team becomes clearer and fully defined over a longer period of time. However, the premisse is that this total value is more than can possibly be delivered otherwise. In fact the general view is that this value is much more.

However, there is another important difference: the entire process of defining portions of value is done by the team itself. In close cooperation with the product owner, a person responsible for the business value by being the voice of the business, the team commits itself to delivering those portions within one sprint, and the team learns to do so without failure: within the time frame of the sprint, usually two weeks. Plus the team delivers the functionality in a complete state: including testing and deployment, using what is called continuous integration.

What is the role of the scrum master in all this? The scrum master might be seen as the closest equivalent of the project manager. If the team is doing all the work, including most of what a traditional project manager would do (such as planning and reporting), what does the scrum master do? And how does she do this different from a project manager?

The main quality of a good scrum master is that she is not "steering" the team, not doing any planning, and not "pressing" the team when it seems the plan is under siege. The plan is what the team itself manages. Processes installed in the way the team works make sure that the team is able to steer itself more than sufficiently. The short feedback cycles help with that. The product owner is part of the team, the delivery cycles are instantaneous, multiple times a day, and the backlog items the team tackles are small enough.

The main responsibility of the scrum master is making sure that the team can maintain the high pace, that all conditions are optimal, and that the team is sufficiently "isolated" from the politics of the enterprise (funnelled through the product owner who is the link with the actual users of the functionality that is being realised). This facilitating mindset is sufficiently different from the traditional one that it needs extra attention. For some it may be difficult and even impossible to make this transition. For others it may feel like a relief.

I have found that this transition can be eased by another transition that many enterprises are moving through: a change in leadership styles in general. Modern management theories resound with facilitating leadership, flat hierarchies and holocracy. The reason is clear: productivity is higher, work satisfaction is higher, costs are lower. If your organisation is going through a similar transition you will find that it helps tremendously in your transition from a project manager to a scrum master.

Is Agile Killing Enterprise Architecture?

Source: tdan.com

… in plaats van andersom: enterprise architectuur die agile laat vastlopen?

Architecten in het algemeen (zoals Charles in het artikel terecht constateert: "Architects in general don't write code") staan te ver af van wat er daadwerkelijk gebouwd wordt. Als het zóver is gekomen dat ze zelfs niet meer in staat zijn om code te lezen of er met ontwikkelaars over te praten, is het zover dat één van de twee moet wijken (of veranderen). Maar voor enterprise architecten is deze constatering nóg vaker correct. Hoe kun je in die spagaat nog overleven?

Mijn stelling is dat enterprise architecten met een willekeurige ontwikkelaar moet kunnen pair-programmen. En met een executive board member moet kunnen sparren over nieuwe markten. En met een security administrator, en met een HR manager, en met …

Te veel gevraagd? Ik denk het niet. Architecten kunnen zich specialiseren (ik geloof bijvoorbeeld heus wel in een Business Architect, die in staat is met capability modellen te goochelen) maar dan wel graag ingebed in een enterprise architectuur die agile is en niet in een ivoren toren zit.

Onder die randvoorwaarden kan enterprise architectuur ontzettend veel toegevoegde waarde leveren doordat het juist een bijdrage levert aan de agility van de gehele organisatie. Het helpt zelfs organisaties te kantelen, waarbij in meer of minder extreme vorm elke vorm van management die niet faciliterend is wordt afgestoten. Dat kan omdat enterprise architectuur dan wordt tot de inhoudelijke borging van de kennis en vaardigheden van de mensen in combinatie met de organisatie (corporate intelligence). Zie bijvoorbeeld mijn artikel De verantwoordelijke architect.

Zijn die randvoorwaarden afwezig? Dan zou ik mij heel goed afvragen of enterprise architectuur wel toegevoegde waarde levert.

With the growing popularity of Agile, mainly in applying scrum for IT development, issues need to be tackled relating to scaling up the development effort.

Scrum came to birth in small teams that had a lot of mandate, typically 3 to 10 person teams. These days we see Scrum used for major efforts, involving hundreds of developers, testers, and what not. An example of that "scaling agile" is the DevOps teams originating with the Dutch bank ING. Another is the Spotify approach (with its main instigator Hendrik Kniberg who was part of the original team at General Electric where Scrum started, but where also Extreme Programming and Test Driven Development was used).

At the moment we can see several "codified" scalable agile frameworks emerge:

1. Spotify (originated from the company of the same name)
2. DAD (Disciplined Agile Delivery)
3. SAFe (Scaled Agile Framework)

The success in terms of productivity and quality in those small teams was noticeable, and we have a solid body of evidence for the effectiveness of the approach in that context. That body of evidence is still lacking in the scalable approaches. In fact, we see a re-evaluation of the standard scrum practices. Google on "is scrum/agile dead" and you will see what I mean.

That is a good thing. Scrum has now been around for 20 years, and it is only healthy to go back to what scrum originally tried to achieve and evaluate those goals. There are people who are scrum adepts that see the entire "scaling scrum" as a hype. They see scrum as inherently small. However, do not underestimate the power of small groups! As Alan Kay once remarked, a team of 10 can do much more in a period of 5 years than a team of 500 (he was referring to the Software Research Group at Xerox around 1975, in comparison to the massive Java effort at Sun around 1995). Those critics ask the question: "is it really necessary to scale up that big?"

Questions are good.

In this blog post I want to add an aspect to the discussion that I think might be overlooked. The focus is on the process (Daily Standup), the teams (Squads and Tribes), how things are done (Sprints), and the tools (scrum boards). However there is a dependency that is crucial to take into account, and that directly impacts the success of both the small (regular) scrum teams as the scaled ones. That dependency is architecture.

Agile and scrum put a lot of emphasis on small increments that deliver complete functionality. A sprint may last only two weeks, but at the end a result is delivered that is tested and ready to go into production. If the customer at any moment in time says: "budget's up. Give me what you have" he can walk away (after concluding the running sprint) with a product that works for those parts of the functionality that have been tackled.

This can only work if the functionality can be decomposed into small parts that have minimal dependencies among each other. A scrum team learns how to create functional specifications that conform to this requirement. They become better at it in time, but sometimes it is not so easy. You may find, as Kent Beck did on the General Ledger application with General Electric, that the whole architecture is becoming an impediment for further evolution. Too many dependencies, especially transitive ones (if I change one component in the chain, another one further away breaks), made it more and more difficult to break down functionalities into bite-sized bits (that is, able to fit into one sprint). That is when Kent decided to throw away the entire thing, only months before final deployment, and completely rebuilt it with a more resilient architecture.

The fact that this rebuilding was done in only three weeks is revealing. That does not say much about the architecture, although having an architecture that was mostly loosely coupled helped with re-using most of those components, but more about the quality of those components as a result of sprint-based development: fully tested, with clear and crisp functional boundaries.

But the architecture got in the way.

What we need to realise is that not only the process needs to be agile, but also the architecture. Sometimes the process helps in keeping the architecture so. We are building those small increments right? But often this is not scalable. We need to be more aware of the need for the architecture of our solution to be agile, to be composed of loosely coupled, minimally sized components, implementing one responsibility, and related with each other using clearly defined delegation of responsibilities. This is what object-orientation has been teaching since 1972. Remember: it was Smalltalk that implemented object-orientation. It was Smalltalk that was used in the scrum project at General Electric. Object-orientation was and is at the root of it all. I find it hard to visualise a loosely-coupled, high cohesion system without using object-orientation but I'm sure it is possible, but at any rate: when scaling agile processes, scaling your architecture in an agile fashion becomes more and more important. We need to move from this structure:

to this structure:

A graph of minimally interconnected elements.

That is what we want to map onto our sprints, that is how we can "evolve" our systems, that is how to create scalable solutions, whether it is software, societies, or enterprises.

Omdat IT alsmaar nadrukkelijker het concurrerend en innovatief vermogen van bedrijven bepaalt, moeten nieuwe bedrijfsapplicaties sneller worden ontwikkeld en met een korte time-to-market waarde opleveren voor de gebruikers en de organisatie.

Source: dutchitchannel.nl

Omdat IT alsmaar nadrukkelijker het concurrerend en innovatief vermogen van bedrijven bepaalt, moeten nieuwe bedrijfsapplicaties sneller worden ontwikkeld en met een korte time-to-market waarde opleveren voor de gebruikers en de organisatie.

Source: managersonline.nl

… waarbij we niet moeten vergeten dat niet alleen IT het agile gedachtengoed moet omarmen, maar ook de business! Scalable Agile in verband brengen met alom bekende begrippen als "kantelen" en "weg met de manager", concepten die momenteel rondzoemen in de bestuurskamers in het hele land.

Voor grote organisaties zal SAFe wellicht gemakkelijker aanslaan, omdat programma managers, enterprise architecten en product managers hun eigen rol in het raamwerk terugzien.

Source: www.marqit.nl

Scrum for architects: how scrum helps architects to create and sustain an enterprise-wide architecture process.

Slowly we are learning how to use the simple format of short standup sessions, called scrum, to help teams in sustaining impetus. A scrum session typically lasts only 10 minutes, with the participants standing. Discussions, opinions, or other ego-vehicles are not allowed, or the format just does not allow for it. Each participant summarises three aspects of her/his contribution to the team's goals:

1. What is it I have been working on the past day?
2. What problems or hindrances did I encounter and how will I deal with them today, or how can anyone from the team help me with that?
3. What is my goal for the work I will be doing today?

This is a daily format, it is useless to do it less often, and equally counterproductive if the sessions are allowed to last longer.

Now let's introduce the "architect scrum". Organisations may be working on implementing an architecture process, in which the actors are architects or anyone playing the role of an architect. As I've written elsewhere, this role will be played by probably everyone within the enterprise. An architects' role is played each time someone needs to make an "architectural decision" (any decision with transitive effects).

1. The person needs to be aware of decisions that are architectural: what is the characteristic of an architectural decision?
2. The decision needs to be documented or marked as such
3. The decision needs to go through the phases of:
   1. can I make this decision — yes: go ahead, no: consult peers, and make the decision if possible
   2. if option 1. did not resolve the issue: escalate to the next "higher" architecturally responsible person
   3. repeat the phases with that person

There is a bit more to it as we can read in the article referred to above, but this is sufficient in the context of this article.

So we see that architects move about in many levels of the enterprise, and if we have implemented an architecture process, these levels are bound in a controllable and sustainable process with roles and responsibilities clear and unambiguous.

However, these processes are "late bound": they take place in the regular context of concrete decisions and the work that produces the need for those decisions. What a scrum session does for a development or project team, it can also do for the pool of architects, across projects and departments, across the entire enterprise.

What I want to propose here is daily Architect Scrum sessions. These sessions are, different from the standard scrum, not tightly bound to a project, but are bound to the enterprise. We want our architects to be aware of what is happening elsewhere, but also we want them to learn from each other as much as possible. The scrum sessions are not for learning, but for creating avenues for learning: we learn that an architect in another department is doing something interesting or challenging. I may be able to learn a lot from her, because I am on the verge of doing something similar. We can also create ad-hoc cooperation when another architect reports some issues he is wrestling with and I know a solution, or someone who may know the solution.

Architect Scrum promotes an "anarchistic" cooperative mode, which lends itself very well with the support of an architectural Wiki, serving as a non-structured vehicle for knowledge exchange.

What do you think? Do you have something similar?