How to diagnose development productivity issues (1)

Improving the productivity of development teams is a constant thorn at the sides of senior management at tech companies. When confronted, development teams usually offer one of these solutions to improve productivity: "our code base is hard to maintain, so we need a refactor", "our deployment process is too slow; we need to implement CI/CD", or "we need to move to this new framework/tool that reduces the amount of coding". There are more, but this is the gist.

All these problems are usually valid. However, they are very often not the primary, root cause of productivity issues. It is not possible to determine a root cause (let alone propose solutions) without running a diagnosis, any more than a physician can treat a serious illness without running tests ranging from the simple, like heart rate, blood pressure and blood tests, to more complicated tests such as MRI and biopsies.

The software engineering equivalent of these tests are the data in the task tracker (code and runtime metrics are important, but for diagnosing productivity issues, the primary source is the task tracker). Unfortunately, many teams, in their rush to get products out the door, consider the task tracker an afterthought at best, and at worst, dismiss it outright as unnecessary bureaucracy. In doing so, they create a vicious cycle: they do not have the observability needed to figure out why they are constantly in a rush; and the reason they do not have the time to create observability is because they are constantly in a rush. The only way out is to break the cycle.

The first step in breaking the cycle is to address the very commonly and strongly held belief among developers that updating task trackers (such as Jira) is an unnecessary distraction from the only thing that is important: writing code. The reality is that maintaining work records is an integral part of any professional's job responsibilities (consider what would happen to a physician who doesn't maintain patient records or a cashier who doesn't maintain receipts). It is impossible to work in a large team environment if progress remains in the heads of individuals. But this is a topic for another article.

Assuming you now have the buy-in of your developers, you need to make record keeping a frictionless process. Complex project management tools such as Jira, unfortunately do not make this easy, but there are ways to minimise the complexity. Primary among these are: keeping the number of fields to a minimum (e.g. summary, description, type, assignee, estimate, due date), maintaining a simple hierarchy (e.g. epics -> stories -> subtasks) and training and empowering everyone (not just the project managers) to represent their work in the task tracker. Details on this too, will have to be a subject matter for a future article.

Once you get to a place where your task tracker accurately represents all work being done, you are in a position to do two things: a) during the planning phase itself, you can use the task estimates to determine where the bulk of your team's time is going; b) at the end of the project, you can determine which tasks tend to deviate from the original estimate the most. These two are your primary diagnostic inputs. You are now in a position to objectively decide whether the problem is in fact code complexity (if coding estimates are high across the board), deployments (deployments take long enough that they have their own subtasks), skills (only some developers' estimates are high) quality (much of the time goes to tasks of type "bug") or something else altogether.