Finding the catalyst

The apps phenomenon is an example of why short, continuous software development cycles are the only way for companies to create markets or get a head start on their competition in existing markets.

However, the delivery methodology that gets amazing code to market in a commercial form in a matter of weeks is not necessarily obvious. In fact, it is the antithesis of methodologies that have been deemed to be best practice for more than a decade. Many developers find it extremely difficult to adapt their working practices to continuous delivery, partly because it takes courage to fly in the face of conventional wisdom.

More often, the problem is that developers are not empowered to say: "You don't need a better mousetrap, you need a mouse whisperer."

One of the disadvantages of thinking of IT providers as service providers is that it encourages the business to simply hand over its IT requirement and specs and set a deadline - and developers are expected to disappear into their hutches and not bother anyone until they emerge with code.

This bad habit has arisen from good reasons. Time was when software developers were proudly geeky, buried themselves in code, and didn't get to grips with what the business needed. When business objected, the IT industry began to focus on understanding the business in order to write code that would better enable business processes. This was followed by a sideways shift towards enabling competitive advantage. The buzz phrase was "putting the business in charge of IT".

The principle is admirable. But the practical execution of it has gone off at an unhelpful tangent.

There can be no competitive advantage in a development process that takes months or years, a testing process that takes just as long, and, as a consequence, leaves the organisation lagging shifts in the market that have superseded the ones it has been trying to address.

Nor can there be any competitive advantage in a company stifling ideas, especially from a source such as software developers, who by nature and chosen profession, are problem-solvers.

Yes, some organisations are realising that IT should be a partner rather than just a service provider. But IT providers are actually capable of far more than helping a company reach its strategic objectives. They can trigger and sustain continuous performance improvement - through the processes and principles that underlie agile and continuous delivery of software.

There can be no competitive advantage in a development process that takes months or years.

The basis of agile delivery is that, instead of developing software for an entire business requirement, then testing it, then refactoring it, and writing more code, developers deliver working software in much smaller chunks in a sequential and iterative process.

The sooner there is a piece of working software, the sooner feedback can be received from its early adopters and refined accordingly. This enables developers to spot and correct problems early, obviously. Just as critically, it enables the company to accurately create functionality tailored to the specific needs of the end-user. Companies are always addressing their own needs, even when those needs change rapidly.

This is where competitive edge begins. A company must proactively track market shifts - or get ahead of them. Agile software development makes an entire organisation agile.

In addition, an agile approach to software development inherently creates agile employees; people who, quite literally, think on their feet.

When a company's turnaround on software delivery is not only rapid but user focused, users begin to realise their feedback has an explicit bearing on how the software will turn out, and therefore, on how the organisation will perform. They become directly invested in the progress of the development project. They begin to enjoy contributing to the success of the project, and therefore, the organisation.

During the projects that are undertaken, it is clear that very quickly, users at all levels of the company begin to spend more time in groups, usually standing at white boards or around the coffee machine solving company problems, rather than at their desks just performing routine tasks. They pool ideas. They initiate fresh approaches. They trigger a groundswell of organisational thinking and learning that gathers its own momentum.

This spurs the team to think in creative ways about the code they're writing and the functionality they're enabling. The innovation that arises there impels further user involvement. And the cycle of innovation through communication and collaboration becomes self-perpetuating.

This is why software developers need to be empowered to interact more effectively with the business, to help the business understand what is possible.