Agile is the new soundbite keyword, and we will probably hear it ad nauseam in the coming year. So best to get our heads around exactly what it means.
The term has gained popularity in software development circles. It helps to understand the progression over the decades to where Agile is an accepted and approved approach.
In IT software development from way back in the 1970s, the way projects were approached is now called Waterfall. That’s because each stage (requirements gathering, specification, development, testing etc.) was completed before the next stage began, like a series of waterfalls on a river.
A project was estimated in its entirety at the outset. A large proportion of the total effort and cost was invested at the beginning to investigate and agree requirements, translate those into technical specifications, and then plan every stage right through to roll-out and post-implementation support.
Not surprisingly, estimates were very difficult to get right. Sometimes they were way off target, which was the sorry history of many Government IT projects.
To illustrate this point, the author was a software development manager with a secret formula for estimating close to being in the right ballpark. Very simply, I obtained estimates from each team – analysts, developers, testers, trainer etc. – called Expert Opinion estimating. Then I pumped all of them into a spreadsheet or into Microsoft Project, which pumped out a delivery date (elapsed time) at the bottom. My secret formula was to add 150% to the elapsed time. It worked mostly. The fact that it worked showed how frequently projects were underestimated.
An analogy of the Agile approach is seen on our roads when an A road is upgraded to an eight lane motorway. The Highways Agency does not close the entire road until it’s all built. No. They build one or two of the new lanes at a time. They deliver a little bit of usable functionality and then a little more. That’s the core concept of an Agile approach. Each piece delivered is called an iteration.
One of the benefits is that estimating is much more accurate, especially after the first iteration has been delivered. Estimating small chunks is always going to be easier and more accurate than estimating a two-year project, for example.
Agile has another, more obvious, meaning. Organisations can become choked by processes laid down by legislation, regulation or fear of litigation, amongst other reasons. Not until the governance is changed can processes become more agile. Agile is almost always cheaper, is always faster and does not mean poorer quality or greater risk.
Procurement in the public sector can take advantage of agility in terms of collaboration. There is no significant blocker. There is a lack of information, however, of Business Intelligence. By that we mean knowing who else is looking to purchase the same service or product that you want, and at the same time.
