I’ve been quite busy in the past couple of weeks looking after a small team putting the Government Digital Strategy online.
In the words of the policy professionals who actually wrote the words, it was published “as a website rather than published on a website“. This may sound like a small distinction, but it makes it easier for people to link to specific bits, and also means we get the benefit of analytics. I’m hoping that more government publications will start to be published in this way.
Jack, our front end developer, has already written up the geek-eye view of the project on the GDS blog , but the short version is that we had a properly multi-disciplinary team (policy, design, dev..) all working together using GitHub with some compile scripts which use Kramdown to turn the Markdown source files into HTML and PDF.
The best bit is that we’re not finished. As with any good online product, ‘launch’ shouldn’t mean it starts to die. We’ve continued to make small improvements (you can see them for yourself in the GitHub commit history).
We’re also refactoring to extract useful functionality into other projects. The best example so far is the code that Tim and Jack developed to create accessible jQuery bar charts from HTML tables. We’ve refactored that out to be its own open source project called Magna Charta and there are some early working examples of it in action here.
Meanwhile, I’ve been continuing to look after ERTP (demo-ing to the House of Lords recently, a task which required the rather unusual step of wearing of a suit to work).
I’ve also been picking up the product management for a management information dashboard tool, which I can’t really talk about yet but is moving into a second phase of prototype development. (No, it’s not that one.)
I’ve missed doing these weeknotes. I might try to make it a habit.
My second week in the new job and I’m still getting to know people and projects. One thing I do know already is that I’m very happy to be here.
One thing I love about GDS is the scale of some of the projects we get to be involved in. On Monday I was introduced to the ERTP (Electoral Registration Transformation Programme), a project which will let people apply online to register to vote. That’s pretty important. Mat Wall (previously of the Guardian) is the technical architect on the project. His team had already completed their first sprint by the time I joined, but they’d been coping without a product owner. On Tuesday, I picked up that role. Much of the rest of the week was spent getting familiar with the product backlog (expressed as user stories of course) and making sure they were prioritised ready for the start of the next sprint.
On Friday we had our second weekly show and tell, showing various project stakeholders the progress so far. We got good feedback and they were especially impressed to see the choices we’ve been talking about in the past few days delivered already in working code. This is where the power of working iteratively and using agile methods really shows its worth. Lots more iterations to come of course, but we already have an end-to-end product working, and have made a good start on the user experience.
Speaking of which, it’s been really good to work closely with Paul Annett this week, and we have some big decisions to make about the online form. For example, should it be “First name” or “Given name”? Is it “Surname”, “Last name” or “Family name”? Various online (and paper) forms already exist of course, but it’s incredibly inconsistent. While there are some agreed standards for how to pass data around, there is no equivalent for how to describe these things to users. That’s something we should get to fix and define as part of the Global Experience Language that will be used for lots of other government products.
Things I’ve been doing this week:
- Picking up the product manager role for ERTP. Working with the various stakeholders and requirements wranglers for that project
- Making sure the important user stories are captured, and starting to get them prioritised.
- Drafting a plan for bringing in a few developers to work on innovation projects. Lots of re-drafts, and it’s still not done.
- Agreeing next steps for another big project and starting to line up workshops to capture user needs. I look forward to the world being awash with index cards.
- Meeting various departments. I turned down one potential project on the grounds that two weeks wasn’t long enough to do a good job of it. We’ll stay in touch and hopefully work on something for the same team later in the year. More of this sort of thing.
- Lots more bits and pieces with the innovation team, mainly focusing on ensuring user stories are captured and priorities are understood. Everyone loves learning a new thing, so helping people learn agile + scrum stuff is fun.
- Passing on a not-as-tongue-in-cheek-as-it-sounds pet theory: good techies are lazy. Being a lazy developer means you’re more efficient and don’t waste time on things you don’t need to do. I was delighted when I overheard someone subsequently encouraging someone else in the team to be lazy and do the simplest thing that would work, rather than over-develop something.
- Continuing to send my newsletter every week day. It’s up to 270 subscribers now, and I’m enjoying having to find a handful of interesting things to share.
- Setting up some time with Leila to record some more Shift Run Stop.
The first week since I joined GDS has been the predictable whirl of meeting people and trying to start to understand what’s going on. It’s a whole new place, with its own ways of working to understand, and a very different environment.
I must say though, like Paul, I was impressed. I received a security pass on my first day (before lunch, even). I was given a choice of laptop, and picked up a shiny new 13″ MacBook Air a few days before the job had even officially started. The attention to detail here, and the thoughtfulness involved in giving techies the appropriate tools with which to be comfortable and productive, is quite impressive.
So, first impressions: brilliant people, lovely office, lots to do.
I’m the brand new product manager for the Innovation team, and I’m quickly improving my understanding of what we do, and why. I’m hoping to start working with the team to define how a bit better in the next couple of weeks.
The very first thing that struck me about the innovation team is that it’s quite small and has a huge pipeline of work. The team are using Trello to track an impressively long list of potential projects from initial leads through to things being actively worked on and finally to completion. That first ‘leads’ column contains a fairly wide range of different sorts of projects. Some are a couple of weeks work for one or two developers. Some are more like 3+ months effort for a small team. Others involve no coding at all, but things like feeding words in to papers and policy decisions. It’s a great team, and I’m delighted to be part of it. Very exciting times ahead.
In my first five days, I’ve…
- Spent most of my time getting to know the team, as well as meeting people from across the whole department.
- Understanding the work that’s already in progress, how we work now, what’s working well and what we could do differently/better.
- Started lining up a delivery team (we need more developers and hopefully a few developers who can work on innovation projects too).
dadadata [thanks Paul] into a dashboard (including some inspiration courtesy of Bill French’s rather nifty Google docs approach.
- Had my first meeting with an external vendor. Although GDS has a good and growing multidisciplinary team, we definitely can’t (and shouldn’t, and won’t) be building everything in house. I predict some more meetings like this.
- Had my first meeting with another government department to start exploring how we could work together (I predict plenty more of these too.)
At the end of an exciting and busy week, the biggest and most in-progress question at the front of my mind, is this: How will we marry government procurement processes with 21st century approach to product delivery?
Using agile methods means being able to influence iterations of product. Seeing working software as soon as possible and prioritising what goes in to subsequent iterations improves the changes of ending up with something useful, largely thanks to being able to handle (gasp!) changing requirements. Martin Fowler wrote a brilliant essay on ‘The New Methodology’ way back in 2005, in which he talks about predictive vs adaptive approaches, the unpredictability of requirements, and many other implications of (and reasons to use) agile methods.
Meanwhile, here in 2012, it seems the government’s procurement practices may still need to catch up quickly. Contracts usually rely on defining a list of requirements and using these to form a very specific contract with a supplier. This has the theoretical advantage of nailing down the cost, the delivery date and (theoretically) the scope, but the predicted requirements had better be right. They’d also better be right before the project even begins, in enough detail to describe what is needed and when it will be delivered. That’s really not an easy thing to do without the people who will be doing the making, the actual developers, being involved. And if a rigid contract makes it hard to iterate meaningfully on a working approach, what happens if we were wrong about the predicted scope? Not such a big deal for a week project, but for a bigger contract it could be seriously wasteful. You don’t need to look very hard to find examples of where this has happened in the past. A lot.
The good news for me is that lots of people in GDS are already aware of the tensions here and I’m far from the first person to think about the issues surrounding the predictive vs adaptive approach. It seems that several people in the building have already been discussing this for some time. Hurrah. I’ve also just been re-reading Harry Metcalfe’s ideas about “How government’s SME relationship should smell” which he shared at the end of last year.
“… the process needs to recognise that in digital projects (and probably other ones too) success far more often emanates from the close and effective personal relationships of people acting in good faith than it does in detailed specification of process, requirements or outcomes.”
Insightful stuff, and I find myself agreeing with Harry very much. Now to see if there’s something that can be done about it.
I’m looking forward to next week, when I hope to get properly involved in some more discussions about all of this stuff, and a lot more besides. Wish me luck.