You shouldn’t be surprised by this.  Agile is in need of Architecture but you have to seriously question how we are going about adapting and inspecting the role of the Agile Architect in meeting that need.  Funny thing is that it may be due to the fact that mainstream Agile thinking is wrapped around Agile as a small team of hardy souls bringing joy to the masses and angst to ‘the man’.

When you live where we do, working with huge organizations spending enormous sums of money so that hundreds and even thousands of people can build, support, train, maintain, and even (gasp) plan how to handle the information needs of millions of people as they; trade at a local, regional, national, and international level concurrently; seek, provide, research, pay for healthcare;  protect/defend their person, family, home, community, nation, world from threats of others or their own environmental actions; and even download upload whatever they find entertaining in this world; when you live on this side of hill, architecture is at the core of being Agile.  And for the most part, we suck at making it great.  Why is that?

Perhaps it has something to do with what architects hear us say and what they take away with them.  I recently read a great blog Lean & Agile: Are they worth the effort? and made these comments.

It is startling to read such a well read and concise synopsis of what many of my colleagues in the Agile community get wrong in communicating what Agile is.
First Agile is more than just delivering the most valuable parts of what the customer wants.  The bit missing is the important one. – it works as near to perfectly as the team can make it.  Why do I harp (some say nag) on this.  Well, if the most valuable item the product owner has cannot be delivered, say for example a startrek replicator machine capable of making $1,000.00 bills in endless supply.  Then we cannot deliver it.  Sorry, not going to happen.  What else do you want?
So what is Agile, it is a way to deliver the most viable value at any given time and in saying this we begin talking about iterative development where we allow for the rapid delivery of emerging solutions.  You know the ones that are not quite right each time the product people look at them – the ones needing ‘one more thing’.  Agile is great because it delivers what was wanted in a short period of time and then ‘adapts and inspects’ to create the next version of “AH HA’s” the product people come up with.  Great stuff.
Agile also does incremental well.  That is the one that you do when the product is nailed down and you know what the end looks like for the most part.  now we can deeply dive in to what and how we repeatedly create the same product or process.

This does sound like lean but as you so quickly caught on, lean as in manfacturing is not what we do in software.  We do not build the same exact source code and ship it over and over again.  We have that bit down in release.  What the Leanies are talking about is ‘lean principles’ which IMO are basic good engineering practices that aided the allies in winning world war II.  Check out TWI and see what I am talking about.  TWI or Job Instruction Trainng is how to teach unskilled people processes that will permit them to produce highly technical product in a very short time.  If more of the Leanies had time in manufacturing line management they would know this. but that trade and proffession, like phrenology, is a thing of the past.

So what does Agile need to adapt and inspect on?

First and foremost we have not allowed architecture to emerge as a valued member of the Agile team.  There are probably a host of really good rationales for this and I am pretty certain that a therapist would have a field day with all the angst, anger, and other inhibiting behaviors that fostered this feeling and continue to fuel the issues.  Folks it is time to get pragmatic and move on.

There is one reason that I have found that makes this impossible and that is the how today’s Agile Architect defines themselves through their work patterns with each other and with Agile teams.

Agile is a team sport and we treat architects in general and Agile Architects in particular as individual contributors that sit on the periphery of the Agile Team.  Shame on us for being that conventional in our thinking.  Shame on Agile architects for not moving hard enough to show the lack of relevance that attitude has when integrating Agile into large projects and programs.  that word is something we need to use around architecture for a couple of good reasons.  The most important is that it really works well when it is done and it also really changes Agile biases because it rocks the boat into hyper gear.