Measuring software development performance – Part I: Alignment
July 6, 2012 6 Comments
This question is a tricky one. If it is pretty easy to measure the performance of an enterprise, or compare performance of sales or financial departments using business-oriented ratios, the exercise of measuring the performance of development teams seems to be a very hard topic.
Especially when these teams need to create commercial products and innovate, for example in the case of software publishers, a universal measure seems almost impossible to determine.
In particular, it is pretty easy to measure costs, but how can one measure the real value of what is produced? The real value is mostly what will be transformed through sales, and it does not solely depend on the R&D team. Furthermore, there might also be some additional value opportunity in the way it helps the users make strategic decisions by providing relevant information and presenting it in a smart way. So measuring the intrinsic performance of the technical team is not easy.
For enterprise applications, it might seem easier as the value mainly lies in the support of business processes. But digging deeper in to the topic, it appears quickly that the understanding, management and evolution of these processes is a responsibility that spans departments beyond the technical team.
How the development team contributes to improve the way a company manages his business is the key to high performance. And this requires a real collaboration between the software development team and other departments.
In our view, there are five pillars of software development team performance:
- Debt minimization capability,
Those five dimensions are important for having a successful software development team and perform over the long term.
Let us start by alignment. It is probably the most important factor for performance as it has a huge leverage effect, and can create significant differentiation between teams.
Many people only measure productivity (or even worse, just cost) but this does not make sense if nobody really checks how aligned to the business value the development effort really is.
On the following schema, software team #3 produces less than the others (shorter arrow) in terms of quantity. Still, this team will provide more value to its company as its efforts are more aligned with business needs (the projection on the value axis).
And as maintenance cost are strongly related to the amount of code produced, the benefit of a great focus on relevant value will even increase over time, whereas teams 1 and 2 will maintain more non-valuable pieces of code and bear a heavier application debt.
Of course, the obvious issue is that this alignment is hard to measure. How can one really detect the non-productive effort on a project?
Still, our experience of auditing applications and software products demonstrate that development teams often over-invest in technical frameworks and approaches that are way too costly when compared to the value it provides for the business of the company. We often detect non-used code, functions that already exist in standard classes and over-engineering techniques that does not provide any real value in the context of the application.
This syndrome happens because technical people love technology. Then they try to solve issues they don’t even have or apply things they read over the net without really understanding whether it applies to them or not.
Another issue when dealing with alignment is the positioning of the technical team in certain organizations. Sometimes, the technical team is positioned only as a technical resource that has no added-value beyond producing what is decided by the sales or marketing department, without having a word about potential design options.
Once in this situation, you get of course a weak technical team, which then justifies the full lead by the business people. Organizations are then trapped in this vicious circle and are doomed to get no real input from smart engineers that could propose the best design options to optimize the value/cost throughput ratio.
Of course, there are low-value applications with few areas for creativity and only room for detailed work provided by a business expert. But those applications are very likely to be available on the market as packaged software, so why would you develop them in that case?
Teams that went down that road often off-shored their developments to low-cost countries, and most of the time, they lost their ability to induce a major evolution of their offering. And guess what, at some stage, they are often caught back by some major functional disruption on their market, not to mention the permanent need to follow up technology innovation, a challenge all software teams faces.
In our experience, it is only with the contribution of software engineers that you can make a real long-term difference on the market, as those guys are the ones able to make some critical choices that will impact the software development cost with another order of magnitude… for the same value!
In our view, only a smooth and durable collaborative process between people who master technology and those who master the advanced needs of a market can produce new innovative solutions that will succeed on the market. This is the primary reason why agile methodologies are getting so popular. They mostly favor implementation and durability of this collaborative process.
Beyond ensuring this alignment as part of the methodology, there are also ways to evaluate your current level of alignment using external auditing for example. It can help you discover areas of code that could be simplified and refocused on your business.
Another advanced way of maintaining this alignment over the long-run is putting usage data directly into the application. This is especially interesting for SaaS applications as the software publisher can then easily track features that are actually used by their customers. Monitoring usage provides critical information for knowing the value of each feature and choosing the proper areas of investment, based on facts, and not only on customer perception.