Over the last decade I’ve experienced and experimented with many approaches to running machine learning and research-y teams. This has included Kanban, no process, Scrum with 1-, 2-, and 3-week sprints, and many things in between. At this point I’m fully convinced that 1-week sprints are uniquely powerful for creating results for these teams.

This runs counter to my initial way of thinking, which was that short sprints are the last thing ML teams need. This way of working seemed counter-productive for a bunch of reasons (some of which are not entirely true, but certainly people will make these arguments):

  • Sprints require planning ahead and breaking down work into very short milestones, and it’s difficult to plan ML work ahead in the same way that software teams can break down and plan work. This is because ML work can be very experimental and requires open time and space to dig in where needed.
  • ML work takes a long time, experiments can take a while, 1 week imposes artificial limits and process where none is needed. The solution space and experimentation space for ML teams is gigantic, and takes time to explore. 1 week sprints mess with the freedom to experiment, and will suppress innovation.
  • ML teams tend to be more academically oriented, and culturally are more process-adverse than the average software team. Since process requires buy in from the team to be effective, and needs to be something the team evolves and cultivates over time, the energy to start something as extreme as 1-week sprints seems like an uphill battle from the start.

Now that I’ve experienced how powerful 1-week sprints can be for ML teams, I know that many of the above reasons are exactly the reason to try them!

Why I’ve found this approach so powerful:

  • ML work is very open-ended, with a large experimentation space and solution space, and many ways for one to go about the work. It’s possible to spend days to weeks on the same task, for individuals to get into rabbit holes, or go down alleys that aren’t the best use of time. 1-week sprints are a forcing function to check in each week about progress, get feedback from team members, and have at least one concrete learning or outcome. This makes the feedback loop for teams very fast, which is extra-critical in a high-risk and large-solution-space setting.
  • 1-week sprints encourage time-boxing and setting milestones. One can decide that they’ll timebox EDA time to one week, and then at the end of the sprint they can decide whether to finalize a training set the following week, or whether another time-boxed activity will be a better use of time.
  • It brings a sense of energy to teams: with regular progress, regular learning, and regular sharing, there is greater opportunity for team cohesion and cross-pollination of ideas.
  • Sprint planning can be extremely lightweight; practitioners merely need to commit to clear deliverable, and not overthink estimation or selecting the perfect task. With a fast feedback loop, any missteps can be corrected quickly.