I was very impressed when I first read the Agile Manifesto. Strange to think that was just over a decade ago and already the world and his dog say they use Agile to deliver projects. But do they really?
First a disclaimer. Software delivery methodology is not strictly speaking of high importance to an EA; Agile has specifically emerged from software development. But I've managed development and delivery teams often enough, and as is usually the case, when you can do something you find yourself being asked to do it more often. Especially when the management of development isn't competent, the architect can be a ready-made replacement standing in the wings.

So Agile is primarily by and for coders. The principles describe how to best deliver quality software that actually does what the organisation requires. Simply put: "better ways of developing software". But what I notice more and more are businesses which say they're using agile methodologies and I'll get asked about how I use agile in my work. At best, many of these businesses are simply paying lip service to a trend. Others though are using an inflexible interpretation of methodology - often called scrum, though not necessarily true! - to actually introduce a new level of management overhead. The result is the very opposite of what agile intends: developers are lost in meaningless bureaucracy, the quicksand of more management directives.
I believe the purpose of many of these Agile-In-Name-Only methodologies is to try and achieve some management oversight into what coders are doing with their time. Because coders by nature have very little patience with management interference and rarely see the point of making progress reports to a line manager or PM who barely understands what they're up to anyway. But the daily scrum meeting or the need to produce something visible at the end of a two week sprint is perfect for giving the half-competent manager the illusion of oversight. In practice, the result of these impositions of a structure which is at odds with the Agile principles, is wasted time, disgruntled coders and the prioritisation of methodology over delivery. The end result will naturally be lower quality deliverables.

Coders think that if the manager really wanted to know what progress was happening, they'd know already. And I tend to agree. During the development lifecycle there are countless decisions which need making. Some are relatively minor, some are absolutely critical, and a good decision maker should know which is which. If the coder has no-one to discuss options with and if need be make the call one way or the other, then they'll rightly feel that their work isn't properly valued by the organisation. The development manager should be fully engaged with the coding process, but also with the business,and should be promoting the continual interaction between the two. Or, as one of the Agile Principles succinctly puts it: "Business people and developers must work together daily throughout the project."

The next time I'm asked then how I apply Agile methodology in my work, I'll explain that the structure I apply isn't a mandated methodology or a formalised set of meetings. It has to emerge from the team of people - coders and end users and stakeholders - from their personalities and skillsets and schedules. I'm a big fan of the concept of emergent properties and this applies as well to teams of people as it does to any other system. As another of the Agile principles puts it:

"The best architectures, requirements, and designs emerge from self-organizing teams."

Spot on. And don't even get me started on pigs and chickens.....