GOV.UK was recently restructured to help us achieve our 2017/18 roadmap. As a delivery manager, I oversaw the formation of 2 new teams under the new roadmap: Content History and Worldwide Publishing. The aim was to build happy, motivated and productive teams with a strong culture of agile user-centred delivery. This blog explains the steps we went through to start them up.
It all started with a spreadsheet
Before we could start figuring out how we’d work together, we needed to understand the working preferences of each team member. So we started a shared spreadsheet in which everyone added their working pattern, upcoming holidays, seating requirements and a link to their personal profile on the GDS wiki.
From this we identified the best times for all our regular meetings and booked in some time for a team kick-off. Planning, show and tells, and retrospectives all happen in the same half-day every week, leaving the rest of the week as meeting-free as possible. This matters because people who make things work best when they have long stretches of uninterrupted time to work, rather than lots of small meetings breaking up their day.
Setting up the team space
Most people in GOV.UK hot-desk, but teams have fixed locations, with space to visualise our progress on wall space, whiteboards and windows. Meeting rooms are in short supply and people often work from home. So we set up a TV and webcam at the end of our desks so that we can use our shared space for team meetings.
Teams are encouraged to personalise their space to build a shared identity, give the office some character and make it a fun environment to work in.
We also have to set up virtual spaces so we can work effectively online. For us this meant:
- Google drive folder for all team sheets and documents
- Google group for team emails and event invites
- Slack channel for instant messaging
- Trello boards to visualise and manage our workflow
- Wiki page to provide an overview of our team’s work to anyone on GOV.UK
Team charter
The first thing we did in our kick-off meeting was create a team charter to document our collectively agreed team values and working practices. Chartering is a great way for team members to better understand each other’s preferences and lay the foundations for a strong team culture.
To create our charter I posed the question: “This is an awesome team to work on because…” and gave everyone 5 minutes to write their ideas on post-its. Each person took turns to explain what they had written and add their post-its to the wall. This process gave all team members an insight into each other’s working preferences. This includes things we have in common, such as wanting inclusive, non-technical language and short meetings. It also covered areas where we differ. For example, some members of the team need uninterrupted quiet time to get work done, whereas others are happy to be interrupted to answer questions at any time.
At the end, everyone voted on the five things that mattered most to them. The results were put up on an A3 poster in the team’s desk space. It’s a living document that we’ll check our behaviour against regularly and continuously improve via team retrospectives.
Agreeing how we’ll work together
After the team charter session we agreed some of the finer details about working together. I came prepared with my own proposals for how we should work to ensure that there was a structure in place for day 1, but was open to alternative ideas from the team. As with the charter, we collectively own these processes, and they should be continuously improved based upon what we learn as we go along.
We decided to start with a Scrum process and one-week sprints. Some team members hadn’t worked with Scrum or in cross-functional agile teams before, so I gave the team an introduction to both of these topics and encouraged more experienced team members to share what had worked well for them before.
Topics covered included:
- prioritisation and delivery processes
- meeting structures
- when, where and how to document our work
- how to use our various digital tools
- how to record planned leave
A shared purpose
The main purpose of a great product team is to solve problems for their users. So when we started our teams, the final thing we did was hold a full team workshop to explore who our users were, their needs, and how well those needs were currently being met. This gave us a shared understanding about the problems we were trying to solve and why they mattered.
This shared understanding about why our effort matters is key to team productivity. When they understand why what they’re doing is important, they see how it fits into the big picture and they believe in it, and they’ll be more motivated. This increased understanding of users and their needs also leads to more informed decision making, and makes the team less likely to get distracted by tasks which don’t add real value. These are some of the key reasons why we will keep the whole team involved in user research throughout the whole project.
Alan is GOV.UK's Lead Delivery Manager. You can follow Alan on Twitter.
