Sometimes, it’s better to do nothing.

A modern software tech stack is so complicated that strong really-full-stack engineers are quite rare so there’s a skill fragmentation problem in most teams, with the most common being the frontend vs backend divide.

As a result, it’s not uncommon to have frontend people do less important work because they can’t really help backend people who are currently working on the critical-path feature.

Since they can’t help, it seems reasonable to have them work on the next feature which might not be prioritized for the next couple months. By doing that, they are creating code that’s likely going to change again later when teams start integrating. They’re also creating more backlog pressure on a team that’s already a bottleneck.

It’s therefore probably more productive to have them do any of the below, in order of increasing value to the team:

• nothing
• invest in cleanups (code, documentation, tooling)
• invest in learning (maybe learn other layers of the stack?)

Some teams will also measure their productivity by adding up story points or tickets. Things will look great on their dashboards while in reality customers are still waiting on features.

The only Lean/Agile book I’ll ever recommend expands on this idea: This is Lean, by Niklas Modig and Pär Åhlström. In line with the title, it’s a refreshingly short and succinct book :-)