The software development and continuous delivery approach used by ThoughtWorks, the world’s leading agile development and user experience design company, offers an approach by means of which organisations can thrive on uncertainty rather than seeing it as an onerous challenge.
Martin Fowler, chief scientist for ThoughtWorks, one of the authors of the Agile Manifesto, and a keynote speaker at the Agile Africa conference (12 and 13 August 2013), points out that, for many years, software development has been structured around attempts to predict a future desired state of the IT infrastructure as dictated by a future desired state for the business.

Success of the development project is measured by how closely the project adhered to the plan rather than the value it delivered.

“That’s not logical in the context of today’s business environment, where change is continuous. Any software developed according to a 12-month horizon, for example, may no longer be relevant when that time comes.

“A predictive approach resists change and, therefore, limits business agility. By contrast, an agile approach to software development welcomes change, seeing it as a strategic advantage. This confers business agility and, therefore, business value.”

Fowler does not dismiss the need for predictability. “Predictability is a very desirable property. However, believing you can be predictable when you can’t leads to people not handling the situation properly when their plan falls apart in the face of a changing reality.

“An unpredictable situation means that many of the models for controlling projects, many of the models for the whole customer relationship, just aren’t true any more. The benefits – and habits – of predictability are so great that it’s difficult to let them go.

“However, letting go of predictability doesn’t mean you have to revert to uncontrollable chaos. Instead you need a process that can give you control over an unpredictability. That’s what adaptivity is all about.”

From a software development perspective, adaptivity means frequently delivering small pieces of working software. Each piece in the sequence builds upon the previous one and contains a subset of the overall project’s required features. These working systems are short on functionality, but are otherwise faithful to the demands of the final system.

They are fully integrated and as carefully tested as a final delivery. And they involve user feedback from the get-go. This iterative, interactive methodology gives the customer organisation immediate – and continuous – value.

“There is nothing like a tested, integrated system for bringing a forceful dose of reality into any project,” Fowler says. “Documents can hide all sorts of flaws. Untested code can hide plenty of flaws. But, when users actually sit in front of a system and work with it, then flaws become truly apparent: both in terms of bugs and in terms of misunderstood requirements.

“An agile approach also gives the customer much finer-grained control over the software development process. At every iteration, he gets both to check progress and to alter the direction of the software development. This leads to much closer relationship with the software developers: a true business partnership. It also leads to software that is absolutely fit for purpose.

“The question must therefore always be: Did the customer get software that’s more valuable to him than the cost put into it? A good predictive project will go according to plan; a good agile project will build something different and better than the original plan foresaw.

“The basic principle holds true at an organisational as well as a software development level.”