Weeknote—30 June 2023

Storming, Forming, Norming, Performing

We were joined by Rachael Harvey, our new Product Manager for our platform and data operations. Scott sent a slack message setting out our new team structure:

I thought it might be useful send a message to help the team understand a few things and provide some clarity across the two teams behind our Planning Data Service:

  • Data Standards Team
  • Data Operations Team

I’m starting to see more people talking and working across teams, which is great to see, but I’m also aware some of you need clarity on our structure to point your work and conversations to.

Shaping the work

Paul recently presented a goal for both teams to align to “make data faster”. I’m very aware that the direction this helps set may not have changed much for Data Standards people, but this is very different to how Data Operations were previously told to work. We are now all busy trying to align our work to that goal. Rachael has started to work with people to grow her understanding of this space. Please help her with any information you have from the Alpha or Discovery work you have done. I’m very aware there is a lot of knowledge sat with people who have worked on this for some time. We have not always been able to talk to each other for various reasons. It’s great we have started to change that.

Setting goals

Data Operations need to set some new OKRs. I’m aware Data Standards have some, which is a great place for us to start in Data Operations. The ones set for us previously need to be revisited and hopefully we can create some that align us across Data Standards and Data Operations. These will help us create the work we need to do to achieve outcomes for the programme.

Organising ourselves around the work

For Data Operations in particular, we have work to do around how we shape ourselves and work together, reorganising our standups, team sessions, backlog, etc. I doubt any of this will change for Data Standards. Once the Service Map has been produced and we have set some tactical goals, we can start to create a clearer picture of this shape (small squads of people swarming around the priorities).

Prioritising the work

  • Matt is the Product Manager in the Data Standards space and will be prioritising what we work on.
  • Rachael is the Product Manager in the Data Operations space and will be doing the same there.
  • Petrea is running a pre-discovery on how we gather and action our feedback.
  • Swati is our Data Manager, prioritising issues with the data which we need to fix.

The OKRs help align us as a Service Team. Rachael and Matt will work together to shape what we work on; with Paul D’s support and direction setting. I will support Matt, Paul and Rachael where they need and want it.

Talking in your disciplines

We want you all to talk to each other! It is essential for the success of our venture. Paul mentioned this being a lean pipeline which we need to visualise and optimise; we need to continue to talk across the disciplines to make that happen.

Delivery

I’m here to support you with all of the above; whilst trying to make us as agile as possible, as lean as possible and happy in the environment you are working in:

  • Jeremy and Gwen talk about content.
  • Debs and Polly talk about research.
  • Matt, Rachael and Petrea talk about how we prioritise work for the teams and across our OKRs and outcomes.
  • Owen, Mark and Adam and our developers help align the technical work to the OKRs we set.
  • Paul Smith, Sarah Fox and Colm help us design a service.
  • And Swati works with everybody to ensure we’re improving our data.

I think you get the picture.

Paul’s presentation may have not changed much for Data Standards people, but it changed a few things for Data Operations people. To summarise:

  • Talk in your disciplines, but do not work in siloes. We need a full multi-disciplinary team to make this happen
  • Share early and often what you are working on, use threads in slack rather than direct messaging, encourage collaboration
  • Reflect work back against our goal to “make data faster”

We will work together to break our goal down by setting some OKRs and outcomes to create further clarity and help each other build understanding.

Some of us are still only a few months into the work. Please call out dependencies; the biggest blocker for multiple teams working across a service.

I’ve included two pictures. The first might give you some clarity into our new Service Team shape.

Make data faster
OKROKROKROKR
Service Team
Data standardsData operations
Product managementProduct management
User research
Design
Delivery
Content
Technology
Data

The second might give some insight into the pain you might be feeling.

lines of communication

We are working to try and make our lines of communication smoother and easier. If you are not feeling that pain, great, but I’m aware some of you are. Any questions, please do ask.

Our new, single service team are closer to norming on Tuckman’s stages of group development.

Combining user story and value stream mapping

Paul D gave the team a quick introduction to Value Stream Mapping and how visualising the service will help us meet our goal to make data faster.

Sarah worked with Paul, Colm, Petrea and Swati to develop a service map [pdf] which relates to our process map as a Mural board. The team are now contributing questions and data to the board. We particularly need to see the sizes of queues and the time data waits between processing so we can priorise the work needed to reduce the time it takes us to get data into the hands of our users.

Service map

Combining User Story Mapping with Value Stream Mapping is an emergent practice. We will share what we learn.

Paul, Paul and Sarah in Manchester

Visualising and stablising our operations

Swati worked with the developers to visualise our processing so we can prioritise our most pressing issues. We keep a lot of data about our processing, much of which is available in our datasette API. This means we can quickly create reports on how we’re performing, such as this Jupyter notebook which shows how we’ve added few endpoints in the past six months, but have a steadily growing number of collection errors to address. Seeing how our system works is our current priority.

Chart of errors versus number of endpoints

The developers continued work to stabilise our platform. Ernest added alerts from our canary deployments to our slack channel. They are a little noisy, but give us greater visiibility of our operations, which is our focus for this sprint.

screenshot of our canary alarms

Next week

Debs, Paul and Rachel will be at the Open Digital Planning team together day in Rochester, and Paul D is at Open Data Camp 8 in Wolverhampton with his newly decorated laptop.

planning.data.gov.uk laptop