In times of rapid change, what do CIOs need to consider?

The “rate of change” is a clich'e, but the exponential rate of this change is not. Like it or not, it'll continue to be the cause of our greatest challenges, but herein also lies the secret to unlocking greater opportunities and success benchmarks.

For businesses, the ability to change rapidly has long been a survival imperative, however, it continues to become more difficult to keep apace with the accelerating rate of change.

New trends and business models are appearing and just as quickly disappearing, the way we went about planning for change has no fixed rules or logical equations.

Spanish fashion house, Zara, for example, has changed the way it responds to planning its fashion cycles. Like most of the industry, it used to plan a half-annual process for winter and summer, but now it has challenged this model by establishing a cycle of only eight weeks - four weeks for product conceptualisation and manufacture, and four weeks in the store. This scale improvement was made possible primarily through the use of information technology.

And herein lies another enigma in the rate of change discussion; we as IT are co-responsible for the exponential rate of change that we have to respond to: innovation breeds new demand.

Business is relying on CIOs to provide input into the game plan, and IT as a group to provide the capability to both drive and respond to change. As this relates to software development, one of the responses we have seen is the migration from traditional to more agile approaches to software development.

Some companies, early adopters, have shifted lock, stock and barrel to follow a particular methodology (and either embraced or regretted and reversed their decision), others have taken hybrid approaches, while some are still pondering the leap. Whatever the approach has been, successful adoption is all relative to the project at hand, the leadership commitment, organisational culture and team dynamic.

There is no holy grail, even with the advent of newer agile methodologies, most companies are still struggling to cope with ever increasing backlogs of development work. Software is often out of date before it gets released. So the question needs to be asked - why, despite everything we know does software development remain such a risky endeavour?

In our experience, a useful angle to explore is to differentiate between “what the methodology says we must do” and “why does the methodology say we should do this”. Without understanding the underlying principles, one cannot accurately match the methodology to the context. The result is the methodology rules taking precedence over the demands of the contextual situation.

Having encountered this time and again with our clients, we embarked on a number of dialogues with our senior architects and developers; what unfolded after many hours of deliberation is the concept of the differences between development principles vs development methodology.

What are the underlying thoughts that guide a decision? We encouraged our teams to evaluate their development decisions against both these principles and the methodology being used, and to consciously deviate from either of these when the context demanded this. We found that this process resulted in a significant improvement in our overall development effectiveness, improving software agility in both the short- and long-term.

Some of underlying principles we uncovered and adhere to are:

* Quality is the foundation of sustainable software
* Create a deep, shared understanding of the given domain
* Design with elegance, using the power of simplicity
* Build for today, don't second guess tomorrow (it will change)
* Do the hard things first
* Obtain quick, ongoing feedback
* Teach what you learn, and practise what you teach
* Collaborate with clients, colleagues and partners
* Continuously improve

This article is not intended to elaborate on these principles, but rather to highlight the value of the process that we underwent. This process encouraged our developers to think more fundamentally about their task of software development, by challenging them to consider the future impact of their actions today, as well as the (rapidly changing) context for which they are building the software.

Our recommendations to any software development department or organisation is as follows:

* Firstly, do some research on current development principles. And while these principles may initially seem academic, they are an important starting point as a basis from which to develop your own principles, those that are most important for your context.
* Secondly, ensure you understand your current development methodology from the perspective of its underlying principles. Evaluate these principles against the principles that are most important for your context, and decide whether changes are required.
* Thirdly, encourage your analysts, architects and developers to debate and evaluate their software development decisions against these principles (which can sometimes be conflicting). Understand and make visible the short and long-term impacts of the decisions being made.

We have found that the contextual identification and application of simple but important development principles can be a significant lever in enabling the business to compete in times of accelerating change, and we encourage anyone facing challenges in this regard to consider this approach.