Some new rules can make agile development in government an even bigger success story, says Richard Stobart.
There is no denying that agile is working as the de facto way to delivery new IT projects within Government departments, since the launch of Government Digital Services (GDS).
GDS is leading the charge on digital transformation and has itself made a root and branch move to agile development methodologies, which dramatically increase the speed with which usable products are delivered.
Just look at the exemplar GDS projects; teams are working collaboratively using sprints, pair programming and many other agile techniques to achieve their goals.
We are also seeing local councils starting to request agile training to help them not just with the practicalities of coding in an agile environment, but also to deliver service design.
Government has also long used outsourcing to deliver IT projects.
It means it can quickly move with technology trends, keep its basic costs down, flex the size of its teams as projects demand, and of course draw on a much wider range of experiences than any in-house team (not just in public sector, but any industry) can hope to draw on.
It sounds as though everything is working well – but with all this change and flexibility, some parts of the outsourcing equation need new rules to keep pace.
At the coal-face of delivery IT departments get it and are doing it, but procurement and service delivery managers are largely still suck in the old world.
The connection between outsourcing partners and departments is not as effective as it can be and there are two main reasons for this.
Firstly, contracts are still being written for whole projects, based on functional specifications and fixed contract periods.
This is not compatible with agile methodologies as underlying the whole premise is the pretext that things will change from what was originally intended.
The best way to structure agile projects is with smaller contracts, starting with an Alpha phase.
This phase is focused on discovering user needs, where an outsource partner, product owner and internal team can build relationships and get under the skin of the project.
The only pieces of the puzzle that should be fixed at this point are what you want to achieve and why – not how.
The job of the Alpha phase is to validate the goals and establish criteria that will impact service development, the scope of work and contracts yet to come.
These smaller contracts then follow on as development gets underway, and are based on realistic expectations for all parties.
Secondly, there should only be one team, not an internal team and external development partners.
The one-team ethos is critical to success in agile, particular when there could be multiple organisations involved in a project.
With a goal of 25% of G-Cloud procurement going to small businesses this is becoming more common – several small businesses providing skills to a single project.
Suddenly everything is starting to sound complicated: where internal teams were once fixed they are distributed across the organisation, and your external partners might well be too.
The role of the service manager, who is a representative from the government department is key to forming these relationships and the one-team ethos because he or she is deeply involved in the daily project management and service delivery.
These are some of the reasons why I believe some new rules are required for outsourcing, if agile is to be as effective as it can be.
Agile methodologies are structured, and designed to cope with all of the challenges outlined above, but distributed teams can and do fail.
Teams are more distributed than ever before, but they are also more fluid, and that is an opportunity to be more effective, agile and reduce the risk of failure.
Agile itself is already proving its effectiveness within government, but it can achieve even more if we all get these few things right.
Richard Stobart is founder & CEO at web and mobile development company Unboxed Consulting
