Scrutinising Digital

I had a chance at the recent LocalGovCamp to find some like-minded souls (including the wonderful Dave McKenna) with whom to explore a question that has been interesting me for a while: how do you reconcile 21st Century approaches such as Agile with the 20th century style governance that exists within local authorities.

For those who are familiar with digital but less familiar with what I mean by Scrutiny I can point you to a proper understanding here or for the purposes of this blog I can simply say that when the Leader and Cabinet style of council governance was created in an attempt to secure more joined-up, quicker, decisions this involved putting a lot more power in the hands of a relatively small number of individuals. To provide checks and balances to this, councils have “overview and scrutiny” which requires that other councillors formally review the decisions of the Cabinet, and have certain powers to require the Cabinet to think again, as well as providing a public airing of tricky issues. This can sound quite adversarial but many councils are using Scrutiny as a constructive adjunct to their activity. The processes of scrutiny can be quite formalised, and are typically arranged as a cycle of regular but infrequent meetings, and are typically quite paper-heavy with bundles of largely textual documents issued quite some time in advance of the meeting. It’s worth noting that some councils don’t have this system of governance - the link above can help with that.

The potential issues arise because agile and service design approaches, whilst being clear about the ultimate outcomes, are resistant to the fulsome specification of tangible deliverables and are inherently exploratory - the design of the solution follows discovery and definition. A council may start with the assumption that a new IT system is needed but the process may reveal that it is not, that straightforward changes in working practices may suffice, or that the “big system” expected may actually be about using an App, or using well established systems such as Facebook or Eventbrite rather than inventing from scratch. For governance processes that are used to being super-clear upfront about exactly what will happen, and exactly by when, and at exactly what cost, there is a clash. This is further exacerbated when, as in an agile sprint approach, the work of the team may pivot a few times during the project, for example at fortnightly intervals, so a lot can happen between the drumbeat of bimonthly council meetings! A single scrutiny meeting during the project (say) may not be able to have the kind of impact that it might on a more conventional style (often called “waterfall”) piece of work.

As with anything to do with local government, which has a huge diversity of people, practices, and experiences, it can be hard to generalise. Nonetheless we did get an appreciation of this as an issue which is likely to become more and more significant as agile-style approaches become more commonplace, and as the projects become larger and so more likely to get on the radar of the formal Scrutiny processes in councils.

Contested Spaces

Some of the areas of difference and discussion are:

The role of elected members as user-researchers, or as participants in the process. By being connected to their communities and often deeply interested in what people actually want from services, members are potentially very well placed to contribute to user research. Against this, people who are integrally involved in a project in this way may find it hard to stand back and scrutinise the final result - involvement may lead to groupthink. It may blur officer/member boundaries. Different councils will have different views and experiences of this. Diversity is good!

Scrutiny of the technology-ideology of digital. We spent less time discussing this particular point, but as well as the familiar challenge of asking elected members to provide challenge to complex technical issues, there can be an ideological overlay here. Choices for example of open source versus closed systems can be in part about technology but can also be about ideology - what kind of council do we want to be - and are therefore quite legitimately something in the member domain; even if one might not want ideology to trump all other considerations, it has a legitimate role to play.

Whether scrutiny can be a continuous process. There may be a very valuable role for task and finish member groups to sit alongside the agile processes, which can involve the subset of members with time and interest but still allow others to provide oversight and challenge. One council has its innovation lab - where this work is carried out - in the members' area of the council amongst the committee rooms, to make it very easy for members to see the work evolve. CfPS have blogged recently about the need for flexibility in scrutiny to handle greater complexity.

Ten Questions

One of the tools that is suggested by CfPS to support Scrutiny members is the notion of “ten questions” - ie ten example questions that would be good to ask and explore, open up the discussion.

In that spirit we have come up with a list of ten questions, which may offer a starting point for scrutiny councillors in asking questions that are more fit for digital, internet-era projects. Clearly, something that is the result of a 40-minute discussion at localgovcamp isn’t going to have the breadth of a full CfPS production but I hope it’s a useful starter.

Discovery stage

1. How much user research are you doing, and how are you structuring that e.g. exactly which user constituencies are you engaging with?

Definition stage

2. What’s the most surprising thing you’ve learned in the process so far?

Design stage

3. How do you know that you are meeting the user need?

4. How are you making the trade offs between different users’ needs - and where are the irreconcilable conflicts?

5. How are you mitigating any adverse impacts of your solution?

6. Tell me about the trade offs you are making between service quality and cost savings?

Delivery stage

7. How does this work become sustained in the medium term, when the energy of the sprint process has stopped?

8. What savings could you generate if you just had two weeks left - what greater potential would there be with a significant increase in resources?

Throughout

9. How is your team composed (does it have the right mix of skills and involvement) - and how it is engaging the rest of the organisation?

10. Where are your blockages, what is stopping this project achieving its full potential?

I'd welcome further discussion around this.

Lastly, a huge thank you to the selfless individuals who create spaces like LocalGovCamp to let conversations like this happen.