Agile is key to making the most of public-sector IT

Public-sector IT. This term covers a variety of technologies, requirements and outcomes, from small implementations that meet tactical needs within one organization to huge, multi-disciplinary strategies that are dictated by central government policy. What links all these projects together is the desire to improve outcomes for those being served — the public — and to achieve this at reduced costs.

Public-sector IT has attracted a negative reputation in the mainstream media over the last decade, with most of this due to the press reports around IT mega-projects that have not delivered the results expected. This perception is often unfair for the vast majority of projects that are completed successfully. The remainder of these plans all set out with the best of intentions, but became bogged down in politics, technology failures and/or loss of skills on the teams responsible for delivery.

Why did this happen? In my experience, this is because specific deliverables are not linked to aims all the way through the lifecycle of application development and IT service delivery. To avoid these issues in future, public sector IT teams are taking up agile development.

Agile began as a response to the long timescales and issues that were affecting application and software projects. It was created to make development and delivery projects more effective, based on meeting business goals and delivering value. Following its take-up within software delivery, agile has now started to permeate other sections of IT and business processes based on the benefits that have been delivered.

It also is turning up in the public sector, though agencies in a survey last year said they first need to establish automation and standardization.

From a public-sector perspective, the main gain from adopting a more agile approach to planning and delivery is how projects can be broken down into smaller pieces of work that can be more easily managed through to completion. These development plans are based on specific results that can be achieved within a given time frame.

Second, each project is based on a “user story” — a description of what the plan will deliver, given in everyday business language rather than in terms of application development work. By taking this approach, the focus is on the business outcome rather than the work itself.

The overall aim for agile is to deliver projects faster and more efficiently. By orchestrating how the individuals and teams work together, this speed of delivery can help public organizations be more productive. However, there are some specific requirements from the business side of the organization that have to be met in order for agile projects to be successful. This will involve more frequent contact between individuals within the IT, development and business teams, as well as avoiding manual work between each section where possible.

Making sure that this level of involvement from the business is understood and accepted is therefore a critical step in making any agile project successful. Part of this involves understanding requirements management. This involves knowing what issues any section of a project is trying to solve in the first place and then setting up the project to deliver on those specific requirements.

The main problem that can be encountered is that those responsible at the organization may not know what they want, or alternatively only know what they don’t want. Either way, the IT team can set off in one direction to solve one set of issues, when actually the desired result is completely different.

An agile approach can ensure that this feedback is gathered early and acted upon if something is not right with the project from the business team’s perspective. Similarly, if requirements have changed between the initial set-up phase and the delivery date, this can be flagged and changes can be made that keep the project on track to deliver what is needed. By putting collaboration between those at the business end of the organization and IT at the heart of each small project, this potential problem should be avoided.

On the other side of this is dealing with “scope creep,” where requirements are amended or altered continually throughout the life of any project. For traditional IT projects, this can be fatal. The agile method accepts changing requirements during projects, as the emphasis is on getting working software or IT assets in place that can then be adopted or changed down the line.

However, this can mean that there is no effective point at which a project can be called “complete.” This is a serious mindset change for public-sector IT, and it can be responsible for many planned solutions not meeting their objectives. By sticking to small projects with a limited set of deliverables, agile can stop this from becoming an issue.

Part of dealing with this is actually being able to say “no — and being supported in doing so — during a project, and instead shifting these potential new developments into a waiting room for analysis. As agile is based on smaller lead-times and bite-sized projects, scope creep can be reduced.

Within any move to agile, there has to be an understanding of where responsibility lies for delivery. Agile approaches depend on accountability across the whole team for success, so managing requirements is therefore a delicate balancing act between both business and IT.

From a management perspective, all stakeholders must have visibility of what the status is on projects. This means being able to provide the right information and detail to everyone, irrespective of the individual tools or systems that are being used for development, installation or other technology tasks, and then deliver that data in a way that is simple to understand.

This can be harder than it sounds. For a start, information can reside in multiple tools and rely on manual work to bring it together. This means integration work in itself, so that teams can see where everything is in progress.

To provide a complete picture, the link between tools and processes has to be better, as well as automated where possible. This does require effort, but in return it helps keep the emphasis on the workflow and results, rather than the tools themselves.

The ability to slim down and automate tasks should go hand in hand with agile, as it takes out some of the manual work that can hold up development and delivery. The rise of cloud computing alongside release management technologies can also assist in keeping the focus on the results.

As public sector bodies continue trying to cut costs and reduce their spending, agile is an attractive proposition. Even if a full take-up of “Agile” is not appropriate, the focus on agility and orchestration in general should help all IT and professional teams in the public sector be more productive.

For central agency projects, agile is starting to pick up. This will drive the use of agile into more areas of public-sector work that are not directly dependent on IT. The principles that agile stands for — greater focus on delivery, responsiveness to user requirements, more emphasis on collaboration rather than contracts — can be applied to other processes and departments, as long as the circumstances are right.

For the wider public sector, agile can provide a route to improved performance based on better orchestration of workflows. By looking at specific objectives around working systems and closer alignment between business and IT teams, taking the agile approach can help to reduce costs and make those projects more effective, both for the public bodies that are putting them together and for the citizens that they serve.