Innovation is too limited

Of course it would be too risky for software development on behalf of customer organisations to start off as an outright experiment. But, there is inherent experimentation - or innovation - in every project that most developers desperately try to eliminate, because they either don't understand its immense value, or it's been drilled out of them by nervous project managers and clients.

What developers should be doing is using the organic unknown in each project to continuously improve the product they're working on. That way, innovation becomes organic to IT development and, indeed, to the development of a business.

It's not something that's added on once the basics are bedded down. It becomes one of the basics.

Most software development is subjected to rigid constraints, because theoretically, experimentation within an enterprise-wide implementation, spanning years and costing millions, would put the customer organisation at risk.

However, there is equal risk in planning enterprise-wide implementation years in advance, and therefore, without insight into the day-to-day realities of the business situation the solution is intended to address; realities that become evident only once the implementation is under way.

Many developers and organisations are now acknowledging there is a middle way that takes the risk out of both scenarios, by delivering smaller chunks of an implementation on an incremental basis.

Known as agile development and continuous development, this middle way makes the implementation productive very quickly, and also provides clear markers for the next step in the overall project. This not only reduces the possibility of mistakes, it actually creates safe opportunities for experimentation that could lead to market-grabbing innovations.

Every software development project should have, as its end game, the humanisation of software - so it is completely intuitive for the end-user. Software that takes a user hours or days to learn and commits the organisation to costly and continuous user training is, quite simply, bad software.

However, more often than not, software engineers are obliged to produce clunky solutions because of the rigid, all-enveloping way projects are planned, allowing them to test their solution only at the end of a years-long implementation.

In fact, they should be writing the tests for their solutions before they write a single piece of code. This means they see mistakes early, and can correct them before they affect an entire implementation.

To do this, they must understand the problem they're being asked to address.

That's possible only if they have interacted directly with the end-users - and everyone in the organisation has had a say about what the solution should do. Developers and project managers don't realise that, embedded in the process of including everyone's needs and views, is the strategic innovation that every organisation currently leaves to its executive team.

Most IT implementation companies do consult with internal and external stakeholders to get a grip on the business need their new software must resolve. However, the fundamental difference between the conventional approach and that of agile and continuous development is that traditional consultation is focused on locking in an outcome; usually one that tries to cover all possible bases.

Every software development project should have, as its end game, the humanisation of software.

With agile or continuous development, the focus of consultation is to open up rather than close down possibilities. It doesn't start out saying: these are the boundaries. It starts by saying: these are the possibilities.

This gives not just the project but the business a direction, a point on the horizon. It provides an idea of what problems the solution will solve and how it fits into the overall business needs.

Then it's a matter of deciding what's important and delivering on each priority, in sequence, as quickly as possible. This 'inception' phase, which consists of workshops with all stakeholders, shouldn't take more than a couple of weeks. Delivery of the first piece of software should take no more than two weeks after that.

In an iterative process, feedback from users then informs the next piece of development until, step by step, the organisation obtains an overall solution that fits its need precisely and has no unused components.

If the organisation wants to change the direction of the implementation because the market has shifted or it redefines its product set, it can do so easily and without strategic or financial penalties, because it's not interrupting a multi-year implementation whose benefits can be realised only at the end. It's had ongoing value from the original implementation from the start. And, if budget runs out, the implementation to date will continue to deliver the value it began creating from week three or four.

That's true IT innovation.