https://gds.blog.gov.uk/2012/10/10/agile-projects-the-people-side/

Agile projects: the people side

We talk a lot about agile here at GDS. We use agile methodologies to focus on our users. The faster we can build a functioning product, the sooner we can get it in front of real users and start iterating based on their feedback.

This has a number of implications for how we organise our projects and manage our people, and I wanted to explain how that affects they way we work.

Multi-disciplinary teams

In practice, we group our people into small, multi-disciplinary product teams. These teams will work closely throughout the day, often meeting first thing for a stand-up, a very quick recap of previous day’s work and a round up of what they have planned. If an area grows too large we break it out into smaller teams again — no one wants to be in a stand-up of 30+ people!

A typical product team will have a product manager (defining the vision for the product and how it will meet user needs), a delivery manager (agile project manager with a focus on making things happen), a technical architect and then a mix of developers, designers, web ops and content designers. We also have folks focused on understanding our users, including customer insight, user research and product analytics.

Transition team stand up

Matching people and projects

We have chosen to organise all of our “makers” into a flexible pool called the Delivery Team which currently has over 70 people. As requests for skills come into this team, we look at what is needed and then match to someone with the right skills and interest in that area.

We want everyone to have challenging, rewarding work, using their current skills well and stretching them to develop further in their chosen specialism (or in a new area if they desire).

Since we may well move people from one team to another based on the needs of the project, we deliberately keep line management separate from project assignment. Some worried that this would be confusing but in practice it has worked well. Each individual can turn to their delivery manager for project specifics and has their line manager as sounding board and for career, personal development and similar topics.

Harmonising not standardising

Over the past few months we’ve also tried to do things in a similar way across products where it makes sense. For instance, having the same sprint timings makes it easier to move people from product to product; encouraging all our delivery managers to use terminology in a consistent way has also helped us to communicate better.

Don’t do it all by yourself (you can’t)

At the moment we have a number of product teams all running in parallel to build GOV.UK as well as a number of other projects.

In order to meet all the short term demand, we have added to our core staffing with a number of contractors from a range of small and medium sized businesses. They’re working on projects with very specific time-limits, and they’ve help make make sure our core staff have the flexibility & agility to respond to changing needs. They’ve also brought us some external perspectives and practices, which have been helping us to meet user needs in the best way possible.

7 comments

  1. Gerrit Berkouwer

    Good story! How many external people help the core team of 70? And how many weeks in one sprint?

    Reply
  2. Maxine McLeary-Jones

    I really like the idea of a flexible Delivery Team and people’s skills and interests being matched to specific projects. This presents the potential for great delivery and developmental opportunities. It would be good to see more of this type of working throughout government.

    Reply
  3. Meri Williams

    Hallo Gerrit! It varies a lot, but at peak we have had about another 70 folks helping the core team. Some just for a few weeks, others for a few months depending on the project needs.

    Similarly our sprints vary according to the work — the majority are on one week sprints, but a couple of areas (in particular where we are doing platform work where the epics are bigger) we have moved to 2 week sprints.

    Reply
  4. The GOV.UK team | Helpful Technology

    [...] Tom Loosemore, Richard Pope, James Stewart, Ben Terrett and others have managed to establish and nurture. People who could work anywhere, want to work for central government now. Those people, in that [...]

    Reply
  5. What we’ve learnt about scaling agile | Government Digital Service

    [...] defined roles within teams as Meri has said are vitally important. Our teams emerged rather than beginning the project formed with the core [...]

    Reply
  6. What I’ve learnt about scaling agile to programmes @ jamiearnold.com

    [...] defined roles within teams as Meri has said are vitally important. Our teams emerged rather than beginning the project formed with the core [...]

    Reply
  7. Agile Projects: The People Side « Geek | Manager

    [...] This was first published on the Cabinet Office website. [...]

    Reply

Leave a comment