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.
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
Comment by Agile Projects: The People Side « Geek | Manager posted on
[...] This was first published on the Cabinet Office website. [...]
Comment by What I’ve learnt about scaling agile to programmes @ jamiearnold.com posted on
[...] defined roles within teams as Meri has said are vitally important. Our teams emerged rather than beginning the project formed with the core [...]
Comment by What we’ve learnt about scaling agile | Government Digital Service posted on
[...] defined roles within teams as Meri has said are vitally important. Our teams emerged rather than beginning the project formed with the core [...]
Comment by The GOV.UK team | Helpful Technology posted on
[...] 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 [...]
Comment by Meri Williams posted on
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.
Comment by Maxine McLeary-Jones posted on
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.
Comment by Gerrit Berkouwer posted on
Good story! How many external people help the core team of 70? And how many weeks in one sprint?