Weeknotes 1: predictive vs adaptive

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).
  • Briefly getting my hands dirty with a bit of javascript in order to experiment with getting live dada data [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.

3 Comments »

RSS feed for comments on this post. TrackBack URI

  1. // wishing you Good Luck as requested .. it’s certainly going to be fun!

    I particularly like the idea of “loading live dada into a dashboard” — it’s the name I’m going to use from now on for messy data.

    Comment by Paul — February 25, 2012 #

  2. Great post!

    Comment by Nick Reynolds (no relation) — February 25, 2012 #

  3. The bit I’m really looking forward to is when sensible procurement policies feed back into the rest of Government. It’s a big job, but if you could solve it for us, it would be rather nice!

    Comment by thom b — February 26, 2012 #

Leave a comment

XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Powered by WordPress with GimpStyle Theme design by Horacio Bella.
The postings on this site are my own and don't necessarily represent my employer's positions, strategies or opinions.