One of the constant challenges software engineering organisations face is not just how to prioritise the work, but how to prioritise the different kinds of work. That is to say, it’s not just whether project A takes priority over project B, but how to balance this kind of activity against that kind of activity.

What is a “kind of” activity? Well, we can categorise our work in different ways. One organisation I worked with talked about strategic work, tactical work and bug fixing. Strategic work was big product roadmap work; tactical was specific feature enhancements to win pending sales; bug fixing was… well, fixing bugs, but also related things such as addressing technical debt. I’ve worked with a few organisations that distinguish projects from technical enhancements. One team I worked with talked about 3 month, 3 week and 3 day kind of activities. There are many ways to cut it, and we can even look at it in several different ways simultaneously.

The question today is how to ensure and maintain we have the right balance between those categories. We can’t do only projects and ignore the bugs; we can’t only fix bugs and ignore the projects. Once we decide on the right balance between those things, how do we ensure that balance is maintained naturally?

There are answers at two levels: the organisational level and the team level.

At the organisational level we can make big strategic decisions about the balance of teams. For example, in the 3 day/3 week/3 month organisation we had one small team that was continuously tackling 3 day work (bug fixes, tiny enhancements, and so on), we had a slightly larger team that tackled 3 week work (non-trivial enhancements), and two teams that were tasked with the 3 month-ish work (projects).

Other organisations I’ve worked with split teams along more product-like lines: for example two teams dealing with enhancements for business customers and one team working on enhancements for consumer customers.

In both cases—and others like them—we are making a medium-to-long term decision about how we balance our effort. In the 3 day/3 week/3 month situation our medium-to-long term decision was to say “15% of our effort goes onto tackling the small stuff, 25% goes onto bigger wins, and 60% is for long term investment”. We can change our minds and change teams around, but doing that frequently causes disruption. That’s why deciding on that balance is for the medium-to-long term.

At the team level we can simply agree with teams that they should maintain a particular balance of work. In the organisation that talked about strategic, tactical and bug fix work, all teams were asked to keep a 60/20/20 balance of those things. Many teams do this kind of thing naturally—for example, always trying to spend a bit of time each week tackling technical debt. But we don’t always need to leave it just to individual teams. That 60/20/20 split was agreed among all the software teams in collaboration with the product managers. Balance at the team level is much easier to change—it’s not the medium-to-long term commitment that happens at the organisational level.

So we have mechanisms at two levels to ensure we can more easily get the right balance of work, and maintain that. One creates a longer commitment than the other, but they work together.

Photo by sharyn morrow