Outcome focussed developer productivity
Is it really necessary to measure the productivity of developers?
“Developer productivity” is an emotive, and occasionally misunderstood term. It is not the output of individuals that we are seeking to understand, but the effectiveness of the development system as a whole. It does not serve to closely monitor the arbitrary output of individual developers as that alone does not equate to efficiency or effectiveness. An emphasis on understanding the development team’s ability to create outcomes is where the merits of measurement lie. Thus, we seek to understand the broader context of an organization’s ability to develop functional software. Where inefficiencies are identified (e.g. infrequent release cycles or excessive bugs in code), it is likely to be caused by a broader systemic issue, rather than an individual developer.
It’s easy to see why developer productivity is becoming a hot topic again – a few percentage points of efficiency in a large development organization can represent hundreds of thousands of dollars in cost reduction, better time to market and improved product quality. That, coupled with the promise of significant productivity increases from AI code companions, (and even AI engineers, like Devin), mean that CEOs, CTOs and CFOs are more keen than ever to understand the productivity of their engineering workforces.
Unfortunately, measuring developer productivity can be a tricky business.
Historically, metrics like lines of code (LOC) or story points have been used, but these measures often don’t reflect the true value a developer brings to a project. They are also easily game-able – developers can artificially inflate their productivity by writing verbose code or overestimating story point values. Perhaps even worse, they can be weaponised by management and business stakeholders to “crack a whip” on the team through malintent, or apply undue pressure to deliver faster, simply through lack of understanding.
Healthy developer metric measurement begins with understanding the outcomes you’re trying to drive within your team; this means asking and focussing on what the value is of the work being delivered. After all, there’s no point delivering the wrong thing more quickly. This could be reduced delivery time and cost, increased deployment frequencies, or reduced defects and rework. The aim is to identify metrics that will provide insight into these areas and guide you towards achieving your desired outcomes.
This is where modern developer productivity measures, such as those recommended by the DevOps Research and Assessment (DORA) team, come into play. These measures focus on speed and stability of software delivery, and the ability to recover from failure. Instead of counting lines of code or story points, they measure outcomes like deployment frequency, lead time for changes, time to restore service, and change failure rate.
Why should CEOs and CTOs prefer these modern measures?
They reflect the true value of development work
Firstly, modern measures better reflect the true value a developer brings to a project. Software development is not just about writing code; it takes a lot more to solve problems and deliver value to users. It’s working with product owners and BAs to understand requirements. It’s applying best practices to make sure the code will be maintainable. It’s nailing the non-functional requirements. Helping the junior developers who’ll be writing core features in the next years. It’s figuring out a high-quality approach, not just a passable approach. By focusing on outcomes like speed and stability of software delivery, these measures capture the true essence of what it means to be a productive developer.
They are harder to game
Secondly, modern measures are harder to game than traditional ones. Because they focus on outcomes rather than outputs, it’s harder for developers to artificially inflate their productivity. This leads to a more accurate picture of a team’s performance, which in turn allows for better decision making. They also better reflect the impact of less tangible levers of productivity – like the engineer who doesn’t write much code, but trains up more junior staff and drives up coding standards.
They promote best practices
On a related note, these new metrics encourage best practices like continuous integration and continuous delivery (CI/CD), which are key to achieving high performance in software development. By aligning the measures of productivity with these practices, organizations encourage developers to adopt them, leading to better software and happier users.
They support a culture of continuous improvement
Finally, contemporary measures like the DORA recommendations support a culture of continuous improvement. By providing feedback on key areas of performance, they allow teams to identify areas for improvement and track their progress over time. This can help foster a virtuous cycle of improvement, where teams continually strive to deliver better software, faster.
How to get started
At esynergy, we view developer productivity as a continuous journey, not an eventual end. The areas that will yield the most improvement will vary over time, and as the development function within an organization is optimized.
Before you begin: Understand the “why”
The first step to improving developer productivity is to understand what values and outcome the organization wants to achieve. For some, this will mean being able to ship features faster to make a company more competitive. For others, it might be improving the reliability of code that is shipped, and reducing the number of new defects that are created, whilst maintaining a similar release cadence. By defining the desired outcomes, we’re able to understand which organizational changes will have the greatest impact.
Assess Ways of Working
This stage is crucial as it gives an understanding of the existing processes, practices, and tools used across all aspects of value delivery. It helps identify bottlenecks, inefficiencies, and areas of potential improvement. It’s vital to look beyond individual developers at this point, and understand the entire system surrounding delivery, including business analysis, team structure, sign-offs, DevOps infrastructure and more.
Measure baseline productivity
Next, it’s time to get to grips with the current situation. As the old adage goes,
“Not everything that can be counted counts, and not everything that counts can be counted”
– William Bruce Cameron
With an understanding of where we want to make improvements, we define leading and lagging indicators and proxies that we’ll meaningfully be able to track, and will help us make the right decisions. From a practical perspective, there are numerous tools on the market which can help give you insight into DORA and other measures, simply by connecting to your issue tracking, project management and version control systems.
Design outcome-oriented targets
Armed with an understanding of the current state, as well as a set of areas that we want to improve, we can define outcome-oriented targets that will be achievable, but ambitious enough to create meaningful value for the organization. By linking the targets to the outcomes that the company most values, we can maximize the impact of change whilst minimizing effort spent on changing processes that we don’t feel will positively influence the organization’s ability to achieve its broader business goals.
Implement TOM & developer productivity tools
Now that the targets have been set, a clear Target Operating Model can be established to help the organization deliver in the most efficient manner. This will help ensure that all aspects of delivery (beyond lines of code and even DORA metrics) are aligned to support the outcomes that we desire. If we haven’t already, we can also put in place the developer productivity tools that will help both to enable the development capability, and to track its progress towards the outcomes.
Track
The stage has been set and the route has been planned. It’s time to verify that the changes we’ve implemented are having the desired impact. Tracking should be seamless and unobtrusive – the whole aim of developer productivity improvement revolves around removing all impediments to effective delivery, so we must always aim to minimize friction. The best tracking tools rely on little more than clean JIRA / GitHub data – reducing the possibility of gaming and avoiding additional work.
Assess & reassess
Over a long enough period, all organizations change. New challenges arise and new technologies and tools become available. As we mentioned earlier, developer productivity is a journey. To ensure we’re on the right path, we should regularly reassess the outcome-oriented targets. In doing so, we might uncover new areas that are more urgent for us to address than the ones we’re currently focussing on. Better yet, we might have met or exceeded our targets and be ready to push the delivery capability to the next level.
Assessing developer productivity and pinpointing areas for enhancement can be a challenging task. Firms like esynergy offer a multitude of value-driven tools designed to aid organizations across various scales. These tools provide precise insights into developer productivity, enabling an objective evaluation of performance metrics.
Beyond providing tools, partners like esynergy bring to the table a wealth of experience in the industry. This vast experience enables them to guide organizations in defining and integrating improved work methods and practices. They offer a structured approach to improvement, helping to identify weak areas, propose effective solutions, and support the implementation of new working practices. This comprehensive approach ensures not just a temporary spike in productivity, but a sustainable increase in efficiency and output quality.
Author: Leo Ijebor, Principal Technical Consultant at esynergy.