Agile: why do we need it? 

With failures of large scale IT implementations reported to be up to 60% – and an estimated 50% of functionality never used – it’s surprising Agile has not been adopted more widely across the industry. Designing a complex software solution isn’t easy. Each one is a unique entity and there are no master blueprints to refer to. Over the years a number of methodologies have been developed and utilised to manage these projects, with the most widely used being the ‘waterfall approach’. Essentially, this is a defined, predictive process in a sequence of distinct phases. Everything is planned up front: the functional specification will describe in the smallest detail exactly how everything should look and feel. This spec will form the basis of a rigid project delivery plan, which the developers will then adhere to and create the software in accordance with. At the end of the project the completed solution is tested and integrated. Sounds about right? Sadly, it’s not. While in theory, this ensures the project is delivered to time and budget and performs exactly as the business specified, in practice it is quite the opposite. The downfall of ‘waterfall’

To begin with, it’s simply impossible to accurately predict your business requirements in the future – particularly in today’s fast paced world where we’re struggling with boom and bust. But organisations still try to do exactly that. Unfortunately, even by the time the brief is completed their business needs have already changed, leading to a never-ending cycle of alterations before any code is ever written. As for introducing changes when you’re in the development phase – forget it! The other problem is that most of the risk and difficult work is pushed toward end of the project. Drawing up the spec is one thing; delivering the software is another. In reality, users don’t really have all the answers about how a system should operate until they see it in operation. But that doesn’t happen here (which is why every scenario is over-specified in an attempt to get a finished solution that works – a huge contributory factor to the 50%+ of delivered functionality never used). Instead, as things hurtle towards the deadline, testing gets crunched in at the end. If there are errors or ambiguity in the functional specification, they often won’t be discovered until the finished product is delivered. Sometimes misunderstandings can be baked into the very core of a system leading to massive implementation problems and cost overruns.