One of the most used and often abused words in the information technology space over the past five years is ‘agility.’ It has been used to describe the state that modern IT departments should aspire to; the ability for management to adapt to change quickly and even how well staff and customers can adopt new technology, processes and services.
The need to be agile has been the catch cry of consultants, industry bodies, journalists, systems integrators and vendors when preaching the concept to others – but how many are ‘eating their own dog food’ and following the very principles they espouse?
How common is it for any of these players to talk about agility and not practice it themselves? You can guarantee many fall into that bracket – not because they don’t want to be agile, but often because they cannot easily change their own processes. And the longer they have been in business, the greater the legacy they carry and the harder it is to implement change – just like those they are trying to transform.
I now know, from personal experience, just how big an issue this. As a software house specializing in large-scale transaction processing and pricing systems, it is evident the evolution cycle of software is endless. As the code gets bigger and broader, the staffing requirements and processes also become bigger and seemingly more complex.
This is understandable when one factors in time pressures, multiple people working on the same code and customer demands. It also has to account for upgrading of core components, tools, storage and repositories, version control, staff turnover and, of course, security. Is it just me that thinks complexity is directly related to size – the bigger you get the more complex things seem to become and the bigger you get the less agile your operation becomes?
I remember quite clearly the days when programming teams of five or six could produce the code (and quality code at that) of much larger teams today. Small teams worked well together, motivated each other, pushed each other and felt an obligation not to let others down. If any one person was weaker in an area then the rest of the team spent time nurturing them knowing full well that if they were more confident they would contribute more and the load would be evenly spread.
Those were the days when it was cool to be in IT and programmers were thought of as highly qualified engineers, proud of their job roles and their work. Now there are so many ‘graduating’ from colleges around the globe the job has lost some of its shine. Working for big companies is not cool but being in a startup is. Gen X and Y aren’t so concerned about job security, it’s more about enjoying work and life. And there is nothing wrong with that.
However, big businesses, especially in the telecoms and finance areas, still don’t work like that. Security is becoming paramount, strong and stable partnerships with established entities are still required by stakeholders and anything radical or disruptive is viewed as ‘dangerous.’ After all, you don’t see too many startups in Gartner’s leading magic quadrants do you?
Yet, these companies and their partners are the most under pressure to become agile. It’s not impossible to transform, it’s just difficult, disruptive and very costly. I have to look objectively at all my company’s internal processes, working environment, remuneration levels and motivation methods to see what can be changed, without too much disruption, to make it more agile. Only then can one go to customer and partners and espouse agility – from a position of having achieved it themselves.
Similarly, startups with hot new products and loads of agility may not have the experience of working with the ‘old school’ firms and may get frustrated at the way things are done or have always been done. Maybe it’s a good time for established players to invest in their own startups that can relate the proven stuff with the new stuff and couch it in terms that the old guys understand and can live with.
It’s going to be a trade-off for some time yet. There is no proof that the new carefree agile style has longevity, but even many of the old plodding types many have been ‘put down’ already. I’m thinking a foot in both camps might be the best option – for now at least.