Three common misconceptions about Agile in the public sector

Agile methodology has its enthusiastic followers in the private sector, but many civil servants are wary about adopting it in the context of government software development and other public sector procurement – usually without good cause.

Whilst ‘government’ – and all that tends to mean in terms of bureaucracy, accountability and existing methodologies – represents a very different setting to the kind of small, lean businesses that thrive on Agile, this need not be a problem. In fact, if project managers can move past their misconceptions, Agile could be the best thing that has ever happened to public sector software development.

Myth 1: Agile is chaotic and ill-disciplined

Exactly the opposite is true. The remarkable speed and cost savings associated with Agile would be impossible without its tight processes and short feedback loops. Close customer collaboration, clear benchmarks and high levels of transparency are all central to Agile, as well as often very sophisticated technical practices and testing. Traditional approaches to government software development can create the comfortable illusion of a greater level of control, thanks to their complex processes, but in practice they’re actually worse at doing what’s really important. Agile is designed to track genuine progress towards working software that the customer actually wants – and adapting quickly to new information that will improve the finished product along the way.

At the same time, some Agile projects ‘fail’ early precisely because they force issues to be addressed that would otherwise go undetected for much longer. In these cases, failing early is far preferable to spending huge amounts of time and money, only to fail later.

Myth 2: Agile means no planning

Sceptics see the term ‘Agile governance’ as an oxymoron. It’s not; it’s just that Agile takes a radically different approach to planning and flexibility. A nice colourful Gantt chart that sets a detailed schedule months in advance might give you a confidence boost at the outset, but it usually doesn’t take long before the drift starts. At that point, you risk focusing on ‘keeping the plan on track’ rather than embracing the fact that learning as you go gives you the opportunity to deliver a better end product.

Agile techniques delay decisions until they really need to be made – at which point, the decision will be better informed and take into account up-to-date information. It might be anathema to the Waterfall methodology typically used in public sector software development, but it means you’re more likely to get what you really want, rather than what you thought you wanted at the start of the project.

Myth 3: Agile means no documentation

The need for transparency and showing value for taxpayers’ money has impeded the progress of Agile in the public sector. The – inaccurate – perception that Agile equals a lack of documentation raises further questions about accountability. In fact, the Agile manifesto states that working software is valued above comprehensive documentation. Traditional projects often expend colossal effort in creating documentation which won’t be updated or even read after the project is finished. Worse, it can get in the way when someone keeps dragging you back to a specification that doesn’t reflect the client’s current thinking. Documentation for its own sake wastes valuable time when what the customer really wants is working software. Agile aims to produce only the documentation which is truly useful to the customer and the delivery process.