At the Government Digital Service (GDS), we’re always working to improve the efficiency of technical delivery and support. We also try to automate manual processes if possible.
Rotas are useful organisational tools that we use to make sure all tasks and processes are done. They help people know exactly who is accountable for any specific function. Our team has rotas for both core work hours and out-of-hours support.
Recently, we’ve experienced a few challenges with scheduled rotas, including:
- people being on multiple rotas
- different management methods
- a lack of visibility across rotas
These obstacles are familiar to lots of large organisations. Here’s how we’ve dealt with these concerns.
The challenges with our old rotas
Here are the core challenges we faced with our rotas before our work to improve our system.
Lots of rotas
GDS had lots of rotas that were all managed differently. Rotas for non-technical roles were mainly managed with spreadsheets, and for technical roles spreadsheets were sometimes supplemented with alerting and operations software-as-a-service tools.
With different ways of working and the reorganisation of some functions and teams across GDS, people lost track of which rotas they were on and when it was their turn to carry the baton.
Siloed data
By combining our security operations, support and reliability engineering teams into a centralised technical operations team over the past 2 quarters some team members were on multiple programme-specific rotas. While an engineer’s time was centralised to the Reliability Engineering team the rotas were not. This led to various scheduling difficulties.
Staff found themselves on call for consecutive weeks for different things. And they sometimes found themselves accidentally put on a rota when they were on annual leave.
Lack of visibility
Our rotas needed to be visible for people who were supporting a service and for people who depended on other services.
People supporting a service needed to know which service they were supporting and when.
End users also needed to know who was supporting the underlying platform their government service uses and how to contact them. For instance, GOV.UK Notify depends on the GOV.UK PaaS, so knowing who to talk to ensures we can resolve any issues quickly.
How we made better rotas
We built an app
We built an app for internal use using Ruby on Rails, the GOV.UK Design System and running it on the GOV.UK Platform as a Service. Our app aggregates rotas from the alerting services that we have purchased, as well as semi-structured data that was previously distributed across our spreadsheets.
Each programme (for example, GOV.UK Verify) is a “team”, and each team has multiple calendars. A calendar can be either dynamic - which pulls from one of our alerting software-as-a-service providers - or manual, where events are stored in a database internally.
This app let us replace spreadsheet rotas on multiple programmes. The app also gave users - the people supporting a service - a complete view of all the programmes they were supporting.
Having an app with centralised data allows us to add an annual leave tracking system which we can overlay on top of the existing rotas. And it lets us view both rotas and annual leave conflicts for any given team. This means, at a glance, anyone managing a support rota can automatically find any conflicts, without having to make spreadsheets or do manual calendar checking.
We tested the app
We tested with 3 teams and received 2 main points of feedback. Firstly, people said it was still “another thing we have to check” - that is, there was not much difference between checking a few spreadsheets and the app.
Secondly, the initial user interface on the app was not intuitive and did not meet the fourth government design principle of doing the hard work to make things simple. The app did not display information in a way that was easy to understand at a glance.
Iterating our app
Following user feedback, we made changes that fell into 2 main categories. This included:
- making tweaks to existing things to improve the user experience
- adding features now the data was centralised
We rebuilt the homepage to show who was currently on the support rotas for a given team. This means users can quickly see who is supporting a service. What previously took a few clicks to reach is now the homepage that renders reasonably well on mobile.
We also built a calendar export feature, using the open iCalendar (.ics) format to make it easier to display information. The app could already import calendars from the alerting tools using iCalendar, so it made sense to build a feature to export information for calendar software using the same format. Users can generate a link which automatically syncs the right support rotas with their chosen calendar software.
Use our code to build your own rota app
If you want to build an app for your own team to replace custom spreadsheets and aggregate different tools, you can use our code. You can also check out the Alphagov repository to see what other GDS projects we're working on.
Toby Lorne, is a Senior Site Reliability Engineer at GDS
If this sounds like a good place to work, take a look at Working for GDS - we're usually in search of talented people to come and join the team.
