I started as a Technical Project Manager at Moz almost 7 months ago with the goal of introducing and managing an agile process for the Data Science team. Data Science works on data models and machine learning—things like Ranking Factors and Feed Authority—and I learned quickly that the nature of the team would present some unique challenges for applying standard agile practices, one in particular.

The problem

Data science work is experimental, and it’s hard to predict when you’ll be done or if your idea will produce the results you want. For a while it worked just fine to come up with an idea and work on it until it seemed ready, and then send it off for people to use. As the Data Science team and the rest of Moz grew, that didn’t work so well. Coordinating work between three data scientists was harder than Dr. Matt working by himself. People in the rest of the company didn’t really have any insight into the team’s progress, and we needed more coordination with other teams to make sure we were able to turn ideas into working features on Moz sites.

We knew that being agile couldn’t guarantee that all our ideas would turn out great or that we would finish them all that much faster (anyone who tells you that starting agile will make a team faster right away is lying or messing with you), so we set up our process with two goals in mind:

Delivering work regularly over time

Showing results frequently so we could review and plan with our stakeholders

What we do

The key to achieving the results we want has been embracing the time-boxed scrum cycle. It’s common mantra that constraints lead to creative solutions and the limitation of working in two week sprints definitely created changes that have been good for data science productivity.

Since every piece of work we do needs to be less than two weeks of effort we are forced to break down a model effort or research problem into small pieces. We have to get creative in defining pieces of the problem. For example, in the past couple months we’ve worked on combining data from Mozscape, Freshscape, Wikipedia, Bing, and a few other sources into some secret sauce to help with the “(not provided)” problem. (That’s all I can say right now, but there will be more about this from Moz in the near future.) Instead of doing everything all at once, we sliced the problem up one piece at a time from start to finish, and each sprint added a new piece to the whole.

By working on problems this way, we’re able to deliver a prototype or set of data regularly (almost every sprint) for people to review. This has been another key improvement that comes out of adapting our work to the sprint cycle. By reviewing a prototype or initial set of data with our stakeholders regularly, we learn early if we’re off track, get new ideas when there’s still time to work on them, and keep ourselves disciplined about producing something tangible.

All this is sort of obvious from an agile perspective, but it wasn’t natural for Data Science at first. The team has had to shift its way of working from trying to make each part of a solution perfect before moving on to the next step, to learning how to finish something just enough to meet our needs for where we are in the cycle. Now we aim to make something work in one sprint, and make it better in the next, and only if it’s really necessary for what we’re trying accomplish.

Making these changes hasn’t sped up our overall work (yet!), but it has increased the visibility of our work-in-progress and made it easier for us to tell people when we’ll be able to give them something they can use in the rest of Moz.

How you can do it

These approaches don’t just work for data scientists. If you have work that uses new tools or technology, does something you’ve never done before, or are just unsure of how it will turn out, here’s what you can do:

Start small. Give yourself a narrow part of the project to build on.

Give yourself a time limit. Stop working on the problem when you reach it.

Define decision points. At the end of your allotted time review and make a decision about how (or if) to proceed.

Make it work. Don’t try to produce the final version of your project in the first pass, just make something that functions enough to keep you on track.

Acknowledge failure. If something doesn’t work, accept that, figure out what to do next, and move on.