The thing I don't like about words like Agile is that they can mean many different things to different people and organisations. We band about questions like, "do you do agile" as if there is really a single answer to that and that brings in confusion. Ultimately, of course, the intention of an agile programming methodology is that the supposedly skilled programming workforce are not restricted (too much) by management or budgets or programs that are imposed from above by people who don't necessarily know how long something takes. It also aims to be able to react quickly to changes either in requirements or in technology. Of course this is a welcome idea but is in danger of being elevated to some kind of holy grail that trumps anything else, however sensible.
I am talking about process and this is something I hold dear and don't personally believe to be the enemy of agile since process is whatever you make it to be and it should support the best parts of your development rather than cause a lack of agility. Naturally it is easy to over-use process and my question to any part of any process is quite simply, "what does this achieve?". A simple question and one which should be easy to answer by anyone using it. If a programmer cannot answer why, for instance, they have to do a code peer review, then they should ask their manager, if they don't know then it should be dropped because processes with no point causes frustration and definite lack of agility, correct processes, however, do not.
I read today a quote from David J Bland who said, "If your startup is going to get stupider as it scales, I understand why you feel the need to layer on process.", a nice pithy quote that is easy to tweet and retweet but one which sadly misses the point (or perhaps I misunderstand the quote). It is not just stupidity that process is to protect against but human nature including lack of experience, forgetfulness, poorer inter-team communications and corner-cutting. You've heard the phrase, "fool me once, shame on you. Fool me twice shame on me" and the same could be said about software, "make the mistake once, shame on you. Make it twice, shame on the process". To assume that you can ignore process as teams grow is extremely naive. As a lone developer, I know fairly well what I can do well and what I need someone else to check. I know when I am being lazy and need to revisit something and more importantly, I am fully responsible for the entire system because I write it all. This means I can use precisely what tools and checks I need to overcome my own weaknesses and also I know how all the parts interact, there is no communication or understanding issues. Even though I have this luxury, I like checklists for setting up servers so I don't forget to close firewall ports and I like code review checklists that remind me to translate strings and validate web pages before they are processed. I have a process and I am only a 1 developer team, you cannot tell me that any team does not need one.
People sometimes take small or trivial software companies and try and scale this to a multi-national corporate as if they are the same thing. Agile is great for things like Facebook, although they now have enough people to both review things and also to quickly pull the plug on something that doesn't work. Microsoft likewise were agile in the first years but now have thousands of testers so whether they have a good process or not can be covered up (although inefficiently). To assume, however, that your company would win a contract for a banking system or nuclear control system despite not having a process because it is "not agile" is plain wrong.
Process is not the enemy of agile, poor process, however, is the enemy of all industry.