Last week, I went to visit the Government Digital Service (GDS) at their offices in Holborn, invited by a colleague who recently left us on the OPM team to take up a post there. She has been convinced by the way they operate and thinks there's a lot us policy types could learn: so I went to see if she was right.
I visited the team on one of the afternoons that marks the end of one 'sprint' period and the beginning of the next. Sprints are how GDS organise their time: a period of time (in the team I visited, two weeks) to pick some things to do, do them, report back quickly, and move on. This means a laser-eyed, effective focus on action and delivery.
The first thing I watched was 'show and tell', where members of the team report back on their activity during the sprint. This shares knowledge around the team and makes sure there's an awareness of what’s been done and how technical issues have been resolved, while also providing the team with a quick dose of both accountability and applause. This was really where I started to see the agile implementation mindset at work: the team was looking at things that already worked, and trying things and improving to make them work better. As policy makers, we already accept that the perfect is the enemy of the good: agile culture embraces that the good can be the enemy of the functional.
Following the show and tell, I went into a 'retro': a team discussion looking back at the last two weeks under the categories of what went well, what didn't, and what people are unsure or frustrated about. This showed me a collaborative environment where the team supports one another and listens seriously to what's preventing people from doing their best work. (And they gave me an ice cream.)
The last meeting I sat in on was about the work coming up in the next sprint. Unlike the kinds of meetings I'm used to, where this kind of planning would involve several papers (plus appendices), this meant projecting up the work environment and talking through it as a group – what were the priorities, what the result needed to be, and how long it would take. This visual, transparent rundown of workloads helped people make choices on what most needed work in this sprint, and also let the team talk about their barriers and where they could use help (either technically or on capacity).
More broadly, this was the principles of design in action: for me, with a vague idea of what programming is but largely assuming the internet just sort of... happens, it was eye-opening to see the deliberation and care that goes into creating exactly what a GOV.UK user sees, down to the kinds of charts outputs are shown in and the amount of white space. The team I saw were responsive to users, and driven by what they needed, but also used their expertise and knowledge to guide what they do.
All this kind of work means having time. The programmers at GDS like to sit and get on with their work, and they're good at saying so. We have our own versions of this (I work from home if I have something to focus on, or sit in one of the building's quiet spaces) but traditional departments should ensure we have working cultures where time to think and focus is respected – where what matters is what has got done, not where, when or how.
Now, I'm not saying things at GDS are perfect. My visit featured complaints about too many meetings, loud workspaces, and a backlog of work piling up which were very familiar. There are still teams with differing, sometimes competing, priorities, who don't always communicate brilliantly – it's not one giant GOV.UK monolith. But there is a mindset of how the world works and what the organisation is doing, shared from senior levels down to support, which keeps them delivering change steadily, to a high standard. I don't think we can expect to just overlay this mindset on our business-as-usual and organisations and have it go smoothly. There are differences in the environment and context of non-technical tasks. It would need some significant rethinking about how we approach and manage our work. But I do think it’s an approach we could learn from.
So what do I suggest you do? It might get a bit crowded over at GDS if 17,000 policy makers want to come and see them like I did. But GDS people are spreading out across the civil service (for example, GDS staff have piled in here at Cabinet Office to lead the roll-out of new technology across the department). Why not seek yours out and spend some time with them?
Tell us what you think in the comments below, on twitter, or on LinkedIn.
Subscribe to our email notifications of new posts.
Leave a comment