I’m hearing the word “Agile” a lot.  For example,  the Government Digital Services (GDS) team within the Cabinet Office are heavily pushing Agile software development methodologies as the way to avoid the kind of IT project failures for which HMG is (in)famous.   Now, I don’t have an issue with Scrum, Kanban or the overall Agile Manifesto, when they are discussed in the right context and where those using the term “Agile” understand it’s background.   I do take issue with those who believe that liberal use of the word “Agile” to precede any other process or activity will somehow sprinkle said process or activity with pixie dust and make it magically better.  It’s not uncommon to hear the phrase “Oh, that’s not very Agile” in all kinds of completely irrelevant contexts.  It appears that adding the Agile label would likely fix any previously extant issues with respect to poor behaviours, lack of commercial acumen or low levels of technical expertise.
Now for the security bit.   There’s a problem with Agile or, more accurately, some of the more zealous Agile Evangelists/Champions who may not fully understand the practicalities of IT project delivery including the need to hand over a service that can be implemented, operated and (eventually) de-commissioned.   There’s a mistaken view that Agile means you don’t need to do all of the usual up-front work of identifying your requirements, including any constraints of the environment into which your shiny new software must be deployed.  Such individuals may claim that they can iteratively elaborate the user stories during each sprint as they’ll be sat with “the business” and can rely upon the expertise of the product owner to make empowered, informed decisions. 
This is flawed.   
In order for the Product Owner role to function, they must have the background context and subject matter expertise to rely upon.   That’s not to say that they need everything up front; just enough, just in time is a valid approach.   The problem is that not enough is always done to set the initial baseline (or else by way of some kind of “helpline” that the Product Owner can utilise outside of the team).  That kind of leg-work is viewed as “not very Agile”.  In my view,  user stories must be drawn up having considered existing constraints – it is very rare that an application will be stand-alone and not have to integrate with other services.  Take the following as an example of the cause of these issues; one of the principles underlying the manifesto is that
“The best architectures, requirements, and designs emerge from self-organizing teams”
This is often taken to mean that the role of the architect is diminished as the development team is better placed to do architecture.  I firmly believe this is a question of scope.  The development team is clearly better placed to derive the software architecture of the application they are developing.  However, if, for example, an organisation has invested heavily in identity management and security monitoring solutions then usage of these shared services must be mandated in order to avoid the proliferation of unmanageable and, perhaps, incompatible security solutions.   The role of the architect is therefore to ensure that the requirements of the overall enterprise are passed to the development team.  This can be done in a number of ways but it does rely upon the Agile Evangelists/Champions recognising that security is one area where the Fail Fast, Fail Often mantra is utterly inappropriate. 
Don’t believe me?  Go ahead then – launch your Beta, lose your customers’ credit card details and tell me how many of them come back to your live service.