The speed of change
When a user sent a tweet about a possible improvement on GOV.UK, it became a great example of how quickly an agile team can respond to feedback. Chris Heathcote from the GDS design team explains how size doesn’t necessarily mean slowing of processes.
Web development has changed since I was last involved so close to the code 10 years ago. Last week I made my first change on GOV.UK: a tiny change, but one that shows how modern web development can happen in the right environment. Back in the old days I would have FTP’d into the web server and edited the change live; thankfully the web has changed, and in a team of 150 people making things, there are easier ways to deploy and clearer checks and balances to go through.
It started when I saw on Twitter a suggestion that one of our most popular pages, When do the clocks change?, could be better presented.
What followed is a swift version of the formal development process: I made a prototype, that was shared amongst the team for feedback, there was general consensus that it was better, a few tweaks of the code, a content editor reviewed the change, the change was coded in the calendars app, pushed to our preview server, reviewed again, and finally made live - all within a day (and whilst also getting on with creating the next big release of GOV.UK).
I was worried that as GDS grew our ability to respond to users and make sensible changes quickly might be lost: it’s good to see we can code and deploy changes almost immediately thanks to a modern development system and process, even with all appropriate checks from the content, design and programming teams.