Measuring IT Agility
Today there is no two opinions about the need for business to be Agile and every other technology/business trend aims at providing/improving agility to enterprises. Agility is a concept that incorporates the ideas of flexibility, balance, adaptability, and coordination under one umbrella (source: Wikipedia). Measuring Agility – and thus finding out if the initiatives are really effective – is a bigger challenge. I have found the following aspects – categorized into two – to be quite effective in measuring Agility related to IT (from an application / product / initiative point of view).
(ie., looking at the results, gives an indication of the “Agility” at any point in time):
1. Perception of Business: Business feedback on how IT is able to support business – existing as well as changes
2. Time-to-market : Time between business suggesting a change, when the change is actually taken up, and how long does it take to implement the change and went it actually gets live.
3. Maintainability of the system: The time and effort involved (and hence the cost) in handling changes; frequency of changes to the system can also be a factor (for e.g, if the system is not rule based and have externalized control tables, even changing certain parameters may mean changing programs and testing the same);
4. Quality of the system: Number of bugs reported, Number of severity 1 or 2 bugs, time taken to sort out the bugs, instances of Debugging resulting in additional bugs
5. Support(ability): Time and effort involved in supporting the system; responsiveness of the support teams, number and %age of problems resulting in program level changes vs Data level changes
(ie., looking at the current environment focusing on aspects which would have an impact on the “Agility”):
1. Technology stack – OS, DB, Language, any other middleware and their versions – and details on whether they are on the versions that are supported, latest versions, obsolete technologies – as well as availability of skills on each of these (say as a %age of their IT force – as well as from general market trend)
2. Database size as well as Archival strategy – it can play some role - more from a migration strategy view as to whether all the data needs to be migrated to new system (or) if some of it should/can be archived
3. Interfaces – the kind of interfaces that this system supports can be another factor. If it has reasonably good external interface support – which lends itself to newer requirements like Internet support, integration with other applications… then the longer it can be… without having any negative impact on the business.
4. Integration Architecture – a well defined integration architecture helps in reducing the interdependencies across applications and hence make it easy for making changes
5. Infrastructure utilization and Vendor relationship – how quickly the infrastructure can adapt changes in volume, work load and how easy to upgrade/downsize
6. Level of Reuse – Services that are consistently reused across the organization can help in making changes faster (as it is one place to change and test – and implemented across – instead of replicating all through). But this may have a downside, when the change requirements for the same service can arise from multiple sources – which can be conflicting – or at least may make one part of the business feel that their changes are not taken up (such issues would be brought out from the “Results” aspect).
While the above approach is quite adhoc and can be used as to get the first cut opinion, there are many detailed methodologies of measuring agility at a Enterprise level:
- Cutter group has an Agile Assessment offer, where they gather and monitor five core metrics: quantity of function, productivity, duration, effort, and reliability (http://www.cutter.com/consulting-and-training/agile-assessment.html).
- Website of Laurie Williams – leader in measurements of agility – of North Carolina State University http://collaboration.csc.ncsu.edu/laurie/ has various references and publications.
- Agility Index Measurements (AIM) covering Internal Team Communication, External Team Communication, Team Morale, Repeatability (builds, configuration management, tests, etc) , Code Quality , Team Skillset and Capabilities , Sustainability and Scalability, ‘Crisis / Crunch’ mode management.