Retros for data teams

I hear the jury's still out on sprints

(do you get my subtitle joke now)

The skinny on retros

I live for data team discourse. Locally Optimistic in particular writes a lot of good articles on all sorts of data work topics. Data teams as product teams and whether or not to have data PMs is a topic that catches my eye frequently.

I know next to nothing about what it takes to be a PM. I don’t really have an Opinion on whether data teams should have PMs. I love PM Discourse articles because I love the organizational techniques within. The energy reminds me of walking into Office Depot or Staples before the first day of school to get supplies. It’s so appealing. I love breaking work down into smaller tasks and always have. I love checklists and journals and Kanban boards. Seeing that PMs use similar tactics in their work is enough to get me interested, though I know it’s just a small part of the overall picture.

I had some complicated feelings about switching to experience teams at work. Despite that, I was excited to get a PM with the transition. The biggest promise of our experience team switch was more focus in our work. That alone was enough to sell me. Prior to our experience team switch, I was hopping from project to project, providing data support all across the business. It was interesting stuff, but it was difficult to feel like I had deep knowledge of anything.

I enjoy spreading the gospel about how great it is to have a PM and anticipate I will continue to do so in future posts. For now, I’ll share my experience with one new feature of having a PM. Our team has a retrospective every two weeks.

Prior to having a PM, we would have a monthly reflection on our goals and progress toward our OKRs. This strategy definitely worked as well! However, I discovered that a shortcoming of having a centralized data team was that our reflections covered a huge range of projects and goals, and while I love my data homies, I couldn’t reasonably stay that interested in their goals that had very little to do with my own.

An embedded team that’s working towards the same goals though? Now that’s a retro in which I have much more incentive to get and stay interested. In my mind, the main elements that make our retros successful are loose structure, record-keeping, and frequency.

Loose structure

Every other week, my team and I meet for an hour of reflection facilitated by our PM. Each time, she has a different (but similar in spirit) set of four prompts for us in a small grid on a Miro board. The last two sets of prompts for our last two retros have been as follows:

Set 1:

1. Appreciate

2. Continue

3. Change

4. New ideas

Set 2:

1. Liked

2. Learned

3. Lacked

4. Longed for

You can see some similarities in the themes. We make an effort to split our thinking between the positives (general appreciation of one another and specific things we learned/think we should keep doing) and the negatives (missteps we made or things we just didn’t do that we wish we had done). Once we see which prompts she’s picked out for us this time around, we spend between 5-7 minutes total writing our thoughts about the past 2 weeks as it relates to each of the four categories.

Once the time is up, we take turns reading each other the sticky notes and discussing any themes that come up. Sometimes this results in action items, and sometimes it doesn’t. For example, in this week’s retro I expressed my frustration that I lost nearly two days of work time to a pipeline bug. It was entirely caused by Databricks and not anything our team did. There’s not really anything to do about that, but we commiserated.

I also brought up that I was discovering small to mid-size pieces of tech debt as I was working on remodeling some of our assets in Looker. My job can be hectic, so I didn’t feel I had the time to address them. My PM responded by showing me a new ticket type she made in Jira so that we could track our tech debt items and slot them in with our work. This one might seem obvious to the more seasoned among you. Keep in mind our experience teams (essentially embedded) transition is very new, and PMing data folks is quite new to my PM. But as soon as I brought it up, she had a way to address it.

This loose structure helps us focus our discussions every two weeks. However, it’s not so rigid that we can’t veer appropriately off-topic and discuss items outside the prompts but relevant to our retro. The dedicated space to think critically about how our team is functioning and not just what our team is doing gives me a huge feeling of buy-in to my work.

Record-keeping

Each grid that we use for our retrospectives is on the same Miro board. Using Miro for our retros finally convinced me that it is a useful tool. I’ve used it myself several times to try to mind-map my thoughts about different projects. I found it just couldn’t match the experience of actually bubble-mapping on a whiteboard. I think this was primarily because there was too much clicking and dragging involved for my taste.

Miro’s infinite canvas and sticky-note functionality means each of our retro boards is at the same link, offset from each other diagonally on the canvas. I can zoom out and see the product of our retros over time. I can appreciate how much reflection we’ve done and how far we’ve come as a team, even just on a biweekly basis. I like that our previous and current retros are readily available and have the feeling of looking through past furious whiteboarding sessions, like snapshots in time.

Frequency

At the start of our transition to experience teams, our CPO strongly suggested that each new experience team take the time to draft a manifesto based on a Miro template that he provided. I did a leadership program in college where we did that kind of thing in class, so I eat these types of things right up. We made the time to do the manifesto. I love that we made an earnest effort to start out on the right foot. Combining our principles from the team manifesto with retros has been powerful.

I know that if something happens during a two-week cycle that I didn’t love for some reason (whether it’s a last-minute request on a Friday due by EOD, poorly delivered feedback, or an unnecessarily long feedback cycle), I have the space to bring it up in retro. Part of our team manifesto was to not sit on problems and to bring them up before they get big.

I think that’s a great idea! But it can be a lot to ask of an IC to bring up something they think is an issue, especially if the people they are supposed to bring it up to are either their boss or very much senior to them in terms of experience. No one wants to look like a complainer or a killjoy.

Having dedicated space every 2 weeks where we can talk about what frustrated us or what we wish had gone differently removes a lot of that hesitation for me. I know that bringing up any issues I have will not be seen as complaining. This is because I’m generally also expected to come up with ideas of how we could approach the issue differently next time. I haven’t always had an idea for how to do something better, and in that situation, I will admit as much and ask for help in brainstorming solutions.

Having our retros frequently has been helpful to have dedicated, low-pressure time to bring up problems. It also fosters appreciation between us as team members because we also take the time to call out what went well.

But I’m sick of data-teams-should-be-like-software-teams-hype!

I know some data folks can be hesitant about adopting sprint-like practices because data work can and does take longer than 2 weeks to deliver something coherent. But don’t underestimate the social-emotional and positive teambuilding benefits of some sprint-like practices! Try giving your team regular, frequent space to reflect on the good and bad of the previous 2 weeks. It might help your ICs become more proactive in coming up with solutions to their own problems.

Tread with caution—it might also make your team like each other a bit more.