In Enterprise Architecture, we spend a lot of time caring (strongly) about agility.  How do we reform IT (people, process, portfolio) so that the business can more rapidly adapt to strategic change?

From a process perspective, one way to approach the problem of agility is to make it more likely that a project, once chartered, will actually deliver business value, and not just rearrange the deck chairs.  That means, of course, that we need to ask the business to put a measurable value on the things that they do.  The result is scorecards and dashboards and BI reporting.  All excellent stuff.

But there is an underlying capability that is directly stated in the problem statement, but frequently lost in the wave of operational data: system agility.  In other words, what people, process, and portfolio measurements are needed as part of our IT scorecard, so that the systems themselves become more adaptable, configurable, and user-self-service-empowered?

And here is where we can inadvertently fail to measure important things.  Here is where scorecards need to be carefully composed to address the problem.  Measurables drive process improvement efforts like Six Sigma, so failing to measure a key measurable means two things: improvement in agility will be inadvertent, and decisions that reduce agility will not receive proper scrutiny.

Bottom Line: We must be able to measure agility. 

To measure it, we must define it. 

What is agility?

Is agility measured by the time it takes to change a business rule?  How come it takes longer to change some rules than others?  What can we do to find and reduce the root causes of delay in the ability to change a business rule?  Heck… how do you define a business rule?

Is agility measured by the time it takes to deliver a new business capability?  Why can I deliver some capabilities quickly, and others take years? 

Are some capabilities ‘bigger’ than others?  Does the relative size of a capability factor in to the time needed to change?  How do we measure the size of a capability? 

These are hard questions.  Have you answered them in your scorecard?

Some may say: you cannot define change because you cannot predict it.  Therefore, preparation for a specific change is pointless.  It creates bloated designs and expensive software. 

I agree.  But I am not trying to predict a specific change.  I’m simply observing that change, as a force in and of itself, is a normal part of business life.  It is not constant: some years we change more than others.  Change is driven by many things, both internal and external. 

Agility is our ability to respond to change gracefully and with few flaws.  If we, as IT, build processes and solutions that don’t take change into account, the cost of avoiding agility will vastly exceed the cost of embracing it.

I say that we can define agility, measure it, and improve it.  In fact, we must.