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.
Anyone else feel the table is arranged the wrong way around? https://t.co/zuIleyRe
— Caspar Aremi (@caspararemi) June 18, 2012
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).
@caspararemi You're right about the table, so we've changed it today https://t.co/H5arf49U cc @antimega
— Ben Terrett (@benterrett) June 19, 2012
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.
Thanks to Caspar Aremi for the suggestion - whilst we do keep an eye on Twitter for feedback, please feel free to email us ideas and suggestions at govuk-feedback@digital.cabinet-office.gov.uk.
7 comments
Comment by Big, Hairy, and Agile posted on
[...] Heathcote, GDS’ creative lead, gives the example of a proposed improvement, posted on Twitter, about the way a page explains ‘When do the clocks change?. He was able to [...]
Comment by mtraslavina posted on
OK!
Comment by Brickstarter – Brickstarter prototype v0.1, and using sketches to ask questions posted on
[...] Government Digital Services, for instance, are producing contemporary work at high-quality, quickly, and at scale, though some are doing it for public good from outside of that environment, such as the [...]
Comment by chrisheathcote posted on
Paul - I'd say it's due to all of the above, and more. I've worked in supposedly agile environments before where the process was used to push down anything difficult or that the programmers didn't want to do, but the application of agile I've seen here is far more practical. If the change was sizeable, it would have had to be added to a team's backlog (and priority agreed with the product manager), but for this there was GTD-style common sense: something that took between 1 minute and half an hour for each person involved is just worth doing now.
I'll add that having a variety of communication methods within the team helped - Campfire, Google Groups and just being in the same office. I've only been in GDS for a few months and had little knowledge of the build and deploy process, so calling on experts in other teams as necessary was important. Other tools, such as a recently developed design prototyping environment, helped too.
But it's as much culture: there's a real feeling of "see something, say something" / "broken windows theory": if anyone at GDS wants to fix a niggle on the site, or if any of our users suggests a change, it's possible and part of our day to day working to incorporate that. I'm particularly interested in how we can actively monitor and fix information and content design routinely - GOV.UK will include a lot of information and many ways to access that information, and it's our job at GDS to iterate that, and make it all as easy to understand and take action as possible.
Comment by Paul Simmons posted on
Chris - your comments mirror that which I have heard from individual dev's at GDS; it's as much about the work ethic than any particular process or discipline. My agile experience is that such features as this example take longer to prioritise and agree (I guess Campfire, Groups and a stand-up in the office), than it does to implement and test. Since Andres' post hints ("real music") at a major issue, if and when that rears its head, I reckon your team sounds like it's in the best place to respond. Meanwhile I'd love to hear more on GDS, particularly how that attitude is engendered and nurtured. Keep up the excellent work.
Comment by Andres Crespo posted on
Real life of large 21st century public sector websites, not toy toy situations. On a daily basis there are dozens of user requests if not hundreds when a topic hits a nerve, all of that mixed with scheduled changes that do have to take place. Unfortunately, some complaints. Hardly ever a compliment. Paul Simmons is polite and positive by not trying to belittle the team's achievement in his earlier post. However, I may be a bit crueler to be kind... One change, one day thanks to Agile? I feel sorry for whoever is in charge when real music starts to play!
Comment by Paul Simmons posted on
That's a great story, though as an long-standing agile enthusiast I'd like to hear how much of the speed of response was due to process, the technology choice itself, or maybe even the small locality of the function changed. I do not mean to belittle the team's achievement, well done to all involved.