The focus lane

Project planning is easy enough if you work on one project at a time. But when your team works on multiple things at a time and you add maintenance and support tasks, things can get messy and you can lose focus very easily. We have tried a couple of things before we found a process that works really well for us.

The first solution was to separate new development and support tasks. This 'someone always makes progress' paradigm may at first seem very appealing. It turns out to be very expensive though for 2 reasons: The first is that the engineers in charge of support really don't have the knowledge and experience with the software to be able to resolve problems in an efficient way. The second problem is that eventually the engineers focusing on the new development get disturbed anyways more than once to help out.

We stopped separating and now we are a true 'you build it, you run it' team. The real power of this approach is that over time you learn to simplify things, build them with support and maintenance in mind and eventually end up with more robust software in production.

Still, no matter how hard we try, we have to deal with distracting tasks and at the same time get some work done on new development.

We tried a time bound approach, defining two-weekly iterations with a 70% ratio for new development and a 30% time reservation for support and maintenance tasks. The problem with this approach is that more than often we ended up with a ratio not even close to the initial planning. It's just not worth the planning effort when you can't consistently meet the goals.

What we learned in the meanwhile is that when everybody was working on the same feature / support issue / bug, efficiency was really high.

Recently we switched to a 'next value' approach that is really functionality bound. In this approach we define the next set of features that coherently adds value. These features get moved to what we call the 'focus lane'. The focus lane mostly contains new functionality limited to one product / project and everybody on the team will be working on these features. Next to that, when necessary, we have time-slots during the day where we pick up support / production / maintenance issues and work on those as a team. During those slots, the goal is to return to focus as soon as possible.

As much as the 'next value' approach may look like the definition of done for time-bound sprints, we explicitly don't consider time when discovering the next value. We found that the actual time range to deliver the 'next value' ranges from 3 to 6 days. The shorter time frames enable us to focus even more and it helps detect situations where people might strike a dead end.

JIRA agile is an awesome tool that helps us implement the focus lane. We simply define a filter that helps float the focus issues to the top of the backlog and also keep them on top when working on them: