Agile with an "A" and an "a"

Had some interesting conversations lately around "Agile" and "agile". 

Agile

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

--http://agilemanifesto.org/iso/en/manifesto.html

 

agile.

adjective             

1. quick in movement; nimble
2. mentally quick or acute

--http://www.collinsdictionary.com/dictionary/english/agile

In many cases the two are linked - if a project is being managed in an Agile manner then it should also be nimble.  Here's a challenge though...

 

If a project is Agile within an organisation that is not agile then how do you succeed? While your project is trying to deliver quickly, is your infrastructure able to keep up?  If you need to test something externally but the SLA from the network security team is six weeks to open a firewall port then how do you deliver?  This is an extreme example of procedural latency which was previously described here as:

 

"Procedural latency is the often observed phenomenon whereby a system operates in such as way that there is a requirement to follow a particular procedure to effect change.  An easy way to describe this is with some examples of procedural latency:

 

System requires "stop and restart of *nix service/daemon" to effect a change.  This will require a *nix system administrator and require a change request/testing/release weekend scheduling and so on.

 

Data has to be updated in several places and requires scripts to be executed against a database, then services stopped and restarted to pick up the new data.  Again - change request and further procedural latency. 

Procedural latency is a good way to destroy a business rather like slow poison rather than rapidly with an axe."

-- Sell-side Fixed Income FIX reference implementation

 

So, if you are trying to deliver on a two week sprint based cadence yet it takes six weeks to open a firewall port you face vastly increased elapsed time to deliver on a project.  One phenomenon I have observed a great deal in the last few years has been for IT teams working within all manner of firms to effectively give up on dealing with internal infrastructure teams and after getting the firewall opened up appropriately, proceed to prototype and test within off-site cloud based infrastructure. So large financial institutions with A-grade hardware and networks will use AWS, Azure, Google Cloud Platform, Rackspace Managed Cloud etc. rather than wait for internal resources to be made available.

 

That's an understandable action to resolve a micro-level problem, but then the macro-level problem is left unresolved and indeed worsens. Why worsens? There is less pressure being exerted on the teams that are not delivering and so they will feel able to say "where's the problem, no-one is shouting".  Indeed, that's true but it's true because they gave up shouting and moved to another supplier. 

 

Especially within Front Office projects where business pressures to deliver are strong the standard move to bypass bottlenecks and obstructions is understandable.  Often the project sponsor will not have any interest in resolving the infrastructure issues that beset the firm.  This is understandable - how many Heads of Trading are interested in SLAs for switching/firewall/router?  But that is short term smart, long term not so smart.

 

Wise IT management will work to ensure that the immediate Agile deliverables are accomplished and at the same time work to move the entire operation to a more agile model.  That requires the business to understand that budget has to be devoted to resolving boring infrastructure based issues and that simply outsourcing the entire infrastructure will not work unless there is an incredibly well written SLA.  This is where IT folks need to have sufficient political savvy, relationship skills and horse trading ability to work with the business to ensure an acceptable outcome can be reached.

 

In summary, Agile requires agile to work properly.  And for that to work requires business and IT to be aligned to resolve short term and long term issues. 

See also:
Functional and non-functional requirements
Security, the right way
DevOps
Vendor relationship management
Contractor, Consultant, Advisor
FIX implementation: Cost cutting proposal part III
FIX implementation: Cost cutting proposal part II
FIX implementation: Cost cutting proposal part I