Just as there are trends in technology, there are fashions in project management and some feel that agile is poorly suited to government and is just a fad. One of the principle objectives for this project was to demonstrate that an agile approach can work. For us that meant delivering a prototype that:
- demonstrated a user-centred central government, single domain website
- used a small, multi-disciplinary team of developers, designers, editors, sat in the same room
- came in for a budget of £261k and was delivered by 10th May
I drew upon Scrum for a structure to manage the project but I knew not to over do it. In my experience projects can quickly become about the process and not the product, with everyone getting hung up on big 'A' Agile. I claim no particular expertise - I am a practitioner and you have to allow room for pragmatism.
Working iteratively, within an agreed upfront budget and time box allowed us to get a prototype out the door quickly. In that time we were able to deliver two releases of the software before finally releasing to the public 3 days ago. We have been pretty open throughout the development and that has been useful for us as a team and hopefully for those people outside of the project room with an interest too.
Simples?
Mostly.
This is my view of how things developed and some of the challenges we faced.
Obsession with user need
We spent the first two weeks in February recruiting a team from inside and outside of government, talking through the scope, agreeing some design rules and agreeing a vision for the Alphagov product based around the recommendations of Martha's report.
We ended those two weeks with a list of priortised user needs (based around search analytics from Directgov, Hitwise and departments), roughly grouped into functional areas and stuck to the wall. Each card (or user story) represented a user need, prioritised roughly from left to right and top to bottom.
Crucially also there was a fair amount of @tomskitomski and @memespring's product experience. All this was more than good enough to get on with twelve weekly development sprints.
Small 'a' agile
We kept the rhythm of the project with daily stand up meetings, weekly show and tells, and certainly in the early stage of the project we'd get our heads together to work out as a team what worked and what hadn't.
We talked a lot - regular interruptions across the room were accepted, sometimes there were creative tensions but crucially everyone worked alongside each other in the same room with a focus on delivering a product.
The product evolved as we moved through the weeks and our view of the product changed. A language developed around 'glue', 'gov', 'tools' 'guides and answers'. User stories cards became a mix of user needs and placeholders for a bunch of tasks.
We used a backlog and estimated the size of each story card to negotiate the weekly work loads. But the team did not get hung up on the concept of velocity (apart from @jamesweiner who thrived on story points and would try to game the system to deliver a 'winning' week).
Mostly though we organised ourselves around what felt right. In fact, for the last two weeks we relied totally on a list on the wall of 'things to do' - because it was the quickest and simplest way of polishing up what we'd already done.
The now infamous Sprint #5!
We (or rather I) didn't get everything right. By the end of sprint 5 I was just about ready to hang up my Excel and opt for a life at the RSPCA.
One of the challenges was balancing momentum with getting the team together. I started on the project in the last week of Jan, by Feb the 5th we had Richard on board along with Jimmy, Dave, Helen, and Peter. It wasn't until mid-March that we had a full team in one place all of the time. This was disruptive and made syncing design and development through iterations of development and working together that much harder. In Sprint 5 we only delivered a couple of stories and Sprint 6 was equally tough but thanks to a monumental effort and some pragmatic concessions, we delivered. From then on we properly started to fly.
A talented, self-organising team.
Most of the Alphagov team are individually capable of designing and building digital products and despite everyone having a role with a title, the boundaries are difficult to establish in practice. We knew who the drummer was, that be Russ, but everyone was capable of being the lead guitarist - so to speak.
Like every other project team it took us time to settle into each other but by working so closely in one room, with space to draw on the walls, with the minimum of interruptions and a single focus around product we were able to produce a lot in a short space of time. We launched a day later than we announced, partly to do with the rhythm of comms, but happy to suck up an extra day to tweak and take the password off in good order.
The quality and amount of feedback and active debate on Twitter, Facebook and GetSatisfaction since then has been phenomenal. We are responding to feedback and able to iterate the product day by day. That's got to be a more effective way of consulting with people to design products that help them deal with the Government online.
This project was not just about the team in the room. A tip of the hat to Chris Chant and Tony Singleton for taking a chance and giving us the space to do this, and to Jimmy Leach, Neil Williams, Darren Leafe, Simon Everest, David Pullinger, Neil Franklin and many others in the Civil Service that helped make it possible.
25 comments
Comment by Alistair Streek posted on
Jamie,
Please excuse me for very cheekily contacting you. I am a research student at the University of Bedfordshire, and am investigating the use of Agile.
Because I work for an Education Software company, and have previously worked in banks and airlines, I have a fair number of contacts in the commercial sector. I am however very short of Agile users in Government.
Do you think that yourself and your team might be willing to answer a short questionnaire on how Agile is used and perceived by each of you? I am trying to get a sample of more than eight people in an organisation to give myself a bit of a statistical base. However even a single reply is valuable.
My team started off using DSDM, moved to SCRUM (actually we were using SCRUM but didn't realise it!) and now are moving to KANBAN. More flexibility. But we are getting on pretty well with Agile now.
Anyhow - if you would be willing to help me that would be excellent - I will send you a copy of my my results and analysis, which I hope you will find interesting.
Sorry for the cold call, but the relentless search for data has made me somewhat shameless!
Thanks and Regards
Alistair
Comment by One website for the UK Government. Extraordinary. posted on
[...] right. Twelve weeks to develop a prototype web site for the UK government. Agile and Scrum came in handy, and the project lead used a combination of methodology and pragmatism, as he put it, to get the [...]
Comment by A Secretary of State talks about agile | Campaign4Change posted on
[...] Agile does work in government – GDS [...]
Comment by INSIDE GOVERNMENT – how busy the busy bees have been | Government Digital Service posted on
[...] with all GDS product teams, our processes are iterative and agile (with a small ‘a’). This means continuous development based on user feedback, shipping new [...]
Comment by Ted Vernon posted on
It seems like you guys did a good job of integrating UX activities in the Agile process, which can be difficult to do.
Comment by Introducing the beta of GOV.UK | Government Digital Service posted on
[...] as much as possible, and developing in the open. The site is hosted in the cloud. Our processes are iterative and agile, we have daily stand-ups and our walls are covered in whiteboards and post-it notes. Which is [...]
Comment by The mobile question: Responsive Design | Government Digital Service posted on
[...] We wanted to build responsive design into the ‘Citizen Beta’ when we were in the planning phase back in August, but large scale implementations were very thin on the ground. We felt it still had some evolving to do before we were ready to commit to using it, and our priority has always been to get something up as quickly as possible so we can begin iterating. [...]
Comment by Hosting the beta of GOV.UK | Government Digital Service posted on
[...] setting up the variety of servers to support it all. Through all of it we’ve maintained the agile, iterative approach that’s been discussed here before, and that applies to writing content and designing user [...]
Comment by Holding the fort: developing a new Civilservice.gov.uk | Government Digital Service posted on
[...] all of them now but we know that we have to launch and improve as we go on –following the same agile principles as the Single Domain project even though we have chosen a quite different solution to a different project. Rate this: Like [...]
Comment by Susan posted on
Hello,
It seems peculiar that, at a time of massive cuts in every part of government, a technology project has a stated aim 'to demonstrate that an agile approach can work' in government.
My experience of Agile projects is that they cost considerably more than expected, since at their core is the idea of refactoring frequently i.e. expect not to get it right first time and change tack, again expecting not to get it right that time. Then repeat the process continuously.
This approach is familiar to anyone that has looked at government IT projects over the last 3 decades, so this approach doesn't feel like progress.
Comment by Eliot posted on
Hi Susan
Would love to see the statistics behind your assertion that agile "cost considerably more than expected" if you are able to publish them? I presume you ran two parallels projects with the same design problem - both of which concluded with the same answer each of equal quality but the "non-agile" one cost less?
Refactoring frequently is the whole point - continually improving, continually developing, continually reacting to qualitative research and hard data that analytics provides.
This is what a product team would do if they were working on a service - right? Quoting this as "expecting not to get it right the first time" seems a unfair.
Comment by Susan posted on
Hi Eliot,
Thanks for your reply.
I can give rough figures for projects I've recently been part of. An organisation spent £5m on one content management system and then £35 million on a second CMS. The second CMS was developed using agile.
The cost of the second CMS spiralled to £35 million due to the need to constantly re-develop functionality because the product never met the basic requirements.
The reason for this failure was that the agile approach required that the design of the software never looked beyond the current time box. This meant that refactoring was constantly required, not to meet new requirements or to react to a changing business environment, but because the initial design took no account of the basic, and well known, requirements of the system.
As an indicator of quality, the £5m system is currently used to publish content to the web in preference to the more expensive agile developed system.
It is a principle of the agile approach to accept that, within a time box, you will produce very limited functionality, with a view to, perhaps, throwing it all away to start again. This has been the case since DSDM was first developed. It is therefore reasonable to say the agile approach "expects to get it wrong the first time". It's a key axiom of agile development.
Perhaps this is the right approach in some situations - the approach was originally targeted at small projects with small teams. However, monolithic and already costly government projects do not seem the right place to experiment with it.
Especially not with tax payers money and at a time that it is essential to reduce waste.
Comment by Eliot posted on
Hi Susan
If you were able to write more on your blog, or something similar, that would be great (dont want to monopolise this post!). "Content Management System" is a little too generic to really get any insight into what went wrong or right. How much that was to do with the people involved, requirements, designs or the method itself.
Sounds like in your case you had a bad experience, but i'm not sure that should act to smear the whole approach. I'm assuming that for £35m (ouch!) you were contracting an agency - or was this done in-house with a team? How large was the team - who was leading it, with what roles etc...
Would be interested in hearing your thoughts around the "minimum requirements" - especially from a experience/interface perspective (screenshots would be amazing - if possible). I've found the work I did with agile (small a) was really useful as a mechanism for forcing me to prioritise. Especially true when faced with decisions about weather to make the experience sing more or get a wider range of functions done.
As for our budget, we had a very fixed budget. We couldn't afford a "minimum requirement". Price, scope, quality - pick two. Cheap, fast, good - as it were. Though you do touch on the interesting area of MinimalViableProduct.
One thing I would like to directly touch on is your statement that "monolithic and already costly government projects do not seem the right place to experiment with it". To my view, alphagov is exactly *not* that monolithic project. Its an attempt to weave technology (and the web) into peoples' interactions with government. Starting small and picking off particular touch points. Maybe eventually spinning out to be a thing of itself. Hopefully it will grow of its own volition if it is useful to people. Its an alpha and a learning process. A product, not "a project". And *that* - to refer back to your very first comment - feels like progress!
Comment by Stuart posted on
Susan, I think you highlighted the problem when you said the higher cost was due to "the need to constantly re-develop functionality because the product never met the basic requirements." This is never a failure of the development methodology used, but rather a lack of understanding or failure to communicate those basic requirements.
I would look to the person/people responsible for ensuring the product was on track (the stakeholders), and those responsible for ensuring that the requirements are well-understood by everyone on the project. The fact that it spiralled so far out of control without anyone stopping and saying 'hang on, we've done n iterations and are no closer to meeting the basic requirements, let's start again" makes me wonder how it could possibly have actually been an agile process rather than something they called agile because it's a buzzword.
Comment by Paul Annett posted on
We're definitely approaching this from a small 'a' agile perspective, using parts of that methodology as they work with the project but not dogmatically sticking to things that obviously wouldn't fit our workflow or scale of project.
Susan – we are looking at the big picture and not having tunnel vision within each sprint. Also, we're an internal team actively involving stakeholders in the project... I don't know if your Agile project experience was with an external team of developers who weren't close to your user needs, but I can imagine that would definitely be a recipe for disaster.
Comment by Luke Tagg posted on
Looks great.
Just picking up on what Eliot said, would an option for next project be to:
- have a sprint '0' and get the tech set up, environment set up and the 1st sprint's UX/UI done in this iteration;
- so that in sprint 1 the dev team would be developing the UX/UI spec'd in sprint 0;
- and the UX/UI team would be working on the sprint 2 interface in sprint 1
The ux/ui team would always be one sprint ahead then. They would always be available to help within each sprint on the existing sprint design but would one eye on the next sprint. I read about this , haven't put this particular method into practice (yet)... looking forward to seeing it progress - great stuff
Comment by Duncan Sample posted on
@Luke, I agree, but I don't think it's limited to UI/UX user stories. In my project we often have user stories that can't be accurately defined without adequate research beforehand, so in one sprint we put timeboxed research/design user stories, then redefine the implementation user stories, estimate them, then prioritise and implement beginning in the following sprint.
One small example would be system monitoring. You could for instance implement the developer's preference or industry standard component, or you could actually think about what you want to get out of the monitoring solution, by having a look at a few different solution featuresets, then accurately defining the solution for next sprint.
This also helps make sure you don't get stuck mid-sprint with a task that needs discussion with members outside team before implementation.
Comment by Jamie Arnold posted on
Hey Luke,
Thanks for your suggestion. We did have an iteration 0 of a kind and we did get some tech and infrastructure work done (not enough with hindsight) but zero design because @nicepaul was not on board from the get-go.
When things were up speed we were mostly one step ahead on design and that worked well but the staggered team start really hurt us.
Comment by Duncan Sample posted on
Congratulations on the progress so far, and much luck for the future.
Having worked for the past year on a product within the innovation programme of my company (that feels all too much like a government organisation with the amount of bureaucracy), I can imagine the hurdles you had to avoid/encounter on your way with this. Still, it is possible, and your team has proved it.
From the look of the photos you didn't use any specific management tools for this? (eg. Jira) My team is unfortunately spread (at the moment at least) amongst 7 different countries at all extremes of the world's timezones, so finding the right, easy-to-use tools has been critical. It'd be great to see more details about your real life development cycle.
Comment by Jamie Arnold posted on
Hey Duncan,
We were lucky that we had everyone in the same room and most info was on a wall somewhere. We also used PBWiki to capture 'the truth' on stories etc, and Lighthouse for bug reporting.
Jamie.
Comment by Jamie Arnold posted on
Hi Elliot,
Richard and Tom came up with a set of design rules and these became a brilliant guide throughout the project.
Each story was sketched by Richard and we noted a list of 5 or 10 acceptance criteria, with a note on what a a successful outcome really was, plus any dependencies on data sources.
Design started later than dev in our case due to a staggered team start but as designs sync'd up we had mocked up pages designs or page elements with each story. These would often change as we played into development.
We tested before the end of each sprint based on the acceptance criteria and common sense. We did some automated tests, but we probably should have done more.
Richard as Product Lead decided our definition of done and as the deadline approached we switched to a task list prioritised with dots and circles around items on the wall.
The interplay between design/development was difficult for us too. It took us a few weeks to figure out the right balance but we got there in the end - I think to brilliant effect. There was regular debate about how much we should develop first and then add design or do some design up front. We concluded each story warranted different approaches depending on what it was.
Similar experiences by the sounds of things.
Comment by Eliot posted on
From a story perspective how integrated were the functions with their design? Who decided when it was done? Who tested them? What criteria did you use to decide it was done?
As the deadline approached did you have to scale back on how fully fleshed up certain functions were?
Who's expectations did you need to manage when it came to the output?
When you had a initial list of all the stories did you have an IA already in place - what about the look and feel, was their a set of design patterns already in place so the early stories knew how they would act when built? Was the estimate for a story including the design of it?
Sorry - I appear to have just asked a huge list of questions! I only ask as I ran a project in a very similar way (albeit *alot* smaller project team) and had difficulty trying to figure out the relationship between the sketches/design and the development.
We ultimately stopped development at week 2 to allow the designs to catch up. But after that, the development just tried to catch up with the design. A little broken process, and probably not a direct analogy.
Anyway, just curious...
Comment by Eben Halford posted on
Glad it went well mate, never doubted you could make agile work in that environment - now how about a huge NHS IT project............ 😉
Comment by Jamie Arnold posted on
Yeah, why not? So long as I can bring this team with me.
Comment by Tom Loosemore posted on
Over my cold dead body will you be poaching Jamie, Mr Eben Halford! ;o)