Pragmatic Cybersecurity unpublished

Pragmatic Cybersecurity unpublished

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

Agile as an overloaded term

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. 

About the author

Ian Cole
Ian Cole
Ian has been employed with Capgemini since 2006 and during this period has been assigned on a number of public and private sector projects within the various market sectors. Ian’s security interests are in information assurance/protective security; he also has a penchant for deciphering security speak to simple English targeted at a CxO level. Ian is a Security Cleared consultant with over 15 years experience in information security. He has an MSc in IT Security and is a member of CESG’s Listed Advisor Scheme (CLAS), an Associate Member of Institute of Information Security Professionals (IISP), a Certified Information Systems Security Professional (CISSP), a Certified Information Systems Auditor (CISA) and an ISO27001 Lead Auditor.
1 Comment Leave a comment
Lee. Great article and you're totally right. Agile is the new mark of quality/the thing we've all been missing, the blue led lights on your electrical item that screams buy me as I must be better than your current one. The buzz in government around Agile may not be totally correct but I'm seeing it making people pause and reconsider the norm 'could we do this better, quicker and cheeper' which has to be a good thing. Maybe we need to swop the names around so Lean is the new Agile and Agile is the new Lean.. Now there's an opening for your next publication. .

Leave a comment

Your email address will not be published. Required fields are marked *.