The final frontier in agile public services

This article has been published in the March 2019 edition of the Investigo Public Sector Insight Magazine. From the time of drafting to the time of publishing in the magazine, I have been involved with the development of a piece of service design work within Urgent and Emergency Care in the NHS. More on that can be read on the blog post by Dr Sam Shah here.

I took a little break from the public sector around eight years ago focusing more on smart data challenges across digital estates and the necessary evolution of education. During the last year or so I have begun to engage once again in a number of public sector programmes and departments, still on the transformation journey, and discovered a new set of challenges facing transformation teams.

The first thing that is immediately obvious is the explosion in the use of wall space and post it notes! Agile delivery has broken the gates of Prince 2, at least in the office spaces. There is a genuine enthusiasm for designing services around the user need, with the fluidity required to stop or start things without years of change requests and gateway reviews.

At first glance this was a resounding success for everything Baroness Martha Lane Fox had hoped to do when she wrote her letter to Sir Frances Maude back in 2010: Revolution not Evolution in which she looked to offer advice on “how efficiencies can best be realised through the online delivery of public services”; and how the government “can use the Internet both to communicate and interact better with citizens and to deliver significant efficiency savings from channel shift.” The full letter can be read here. However, once inside, this was not what I found.

Agile working is not simply a chaotic way of quickly getting information out the door in little bits of code changes and tweaks (plus post-its). It is a process that relies on a strong surrounding infrastructure that totally supports its freedom of movement and doesn’t stifle its response time or ability to pivot. It dramatically reduces the risk of service failure by breaking the delivery points into much shorter chunks and having very clear roles and responsibilities, ceremonies and a manifesto. What it does not do is go beyond what it is
there to do — nor should it.

In both all the departments and programmes I have come across, there are agile delivery teams, successfully developing products that are passing the GDS tests and moving from Discovery to live services. In the technical delivery rooms, it all pretty much runs smoothly (even if approval to use some of the platforms needed: Confluence, Slack and Jira for example, is often pretty impossible to get, at least not quickly).

But where the challenges still lie are in the supporting infrastructures of governance, finance, PMO and live services management. Even in stakeholder engagement and planning stages, clients still want to know what they are getting and when. They expect the associated standards and training to roll out these products. There is still a degree of uncertainty and distrust because of the apparent vagaries of agile development of digital services.

Furthermore, there is a huge increase in demand for agile coaches to help (an increasingly) senior level of management who are unsure of how to adapt and learn to enable this way of working. Confusion around the role of the traditional assurance and strategy boards and how live services can maintain the same level of agility once a product is deemed ready to move on from its Beta phase, are still very apparent. It would seem traditional governance models have not yet had their revolution.

Finance departments and PMOs struggle to find the right way to marry and measure delivery against business cases that often do not reflect the same final product as originally proposed, because the user behaviour varies in practice. The temptation, in response to this, is to either severely slim down and de-tooth the PMO. Doing so leaves instability in areas such as risk management, formal reporting and finance, all of which are problems the
agile teams working on delivering the right product or service, could do without. Alternative response is to ramp up the PMO and give it enormous power to try to alleviate the pressure and constant requests for updates from the delivery teams. However, the PMO model is still the same and it jars with agile delivery.

Every single person I have worked with in all these areas has been more than keen to work in the ‘new’ way. They want to support the status quo and develop the skills needed or bring in the right coaches and specialist staff. There is, however, an undercurrent of desperation, and anxiety, as no one has a clear overview or oversight of how this works end-to-end and top-to-bottom.

This anxiety seems to have spawned a new requirement for a kind of hybrid service design specialism. Service designers are the only people who really have the skills to create a methodology to this need which is very difficult to articulate. How can you ask for a solution to a problem that is best described as “We have a slightly anxious feeling, and no one really knows why, please can you help?”

It is my belief that service designers are the final piece of this puzzle and should be a part of the roles and responsibilities description of agile teams working in the public sector (or indeed any large organisation with complex governance and a responsibility to deliver products and services). One could argue that business architecture fulfils this role, but I have not yet seen it working to resolve all of the challenges that come with agile working as there still remains a weirdly shaped hole full of uncertainty.

Most people imagine service designers to be glorified UX people and see them very much at the interface between service user and agile development team. But where they are increasingly in demand is front to back, up and down design. They are uniquely positioned to design the infrastructure needed to enable user-centred agile product development, as well as to tackle the challenges around governance, live service management, the role of the PMO and how finance departments can operate in this space with the same level of
accountability and scrutiny. Business architects need to work with service designers and vice-versa– for now. Pretty soon these roles will be a combined skill set and I imagine those people will be extremely valuable.

For me these hybrid service designers are the new wave of geeks that the public sector needs immediately. Ten years ago, it was people who could work with data, who understood how to produce digital tools and services at a fraction of the cost, with reduced risk and higher rate of take up. Baroness Martha Lane Fox, Mike Bracken and GDS made that happen against all odds eight years ago, and it is nothing short of astounding to see how it works now in government. HMRC are exemplars of the agile development of services.

To address this final clash between traditional and agile, which brings about this intangible feeling of anxiety and insecurity, we need to bring in a more hybrid service — skilled designers focusing on operational challenges around governance and assurance. They need to be the ones at the forefront of public sector conferences, technical groups and on stages. They need to be sharing their work and providing as many best practice models as they can. They need to be looking to re-skill, love finding order in chaos but aren’t scared of a pivot
here and there to become a good service designer. I think this will make the post-it note budget realise a tangible ROI.