In business, the delivery of value is about measuring outcomes not effort. Metrics relating to how much time we spend on a project are useful for cost management and the assessment of efficiency, but get us nowhere in terms of understanding functional completeness or user satisfaction. Both matter, but one should not be mistaken for the other; the hours taken to build something can never be an adequate proxy for quality.
By adopting agile practices, through which key stakeholders become more deeply engaged in the delivery process, companies are already starting to focus on the metrics that really matter and improving their likelihood of creating value instead of simply creating completed projects.
However, there is an interesting irony here... Many of the metrics that we would hope to harvest for insight into our efficiency, cost, and quality, such as the resources and time used to complete tasks within the SDLC process, require the kind of consolidated view that can often break down with the adoption of agile.
There are some key elements at this point for a company to attend to if they are to stand any chance of capturing such vital statistics.
Change is Constant
It’s not just source code, but everything across the entire delivery process changes. Being able to capture what these changes are, and capture the relationships between each of these items throughout their history, is a critical element in ensuring a more robust picture of efficiency and release readiness.
A couple of years ago, Forrester Research stated:
Today, application development professionals should look to the process of software delivery change, focusing on change management from need to delivery and back again.
Placing change management at the heart of the software delivery lifecycle is essential when seeking to answer the important questions.
Garbage in, Garbage Out
It’s well understood in any part of an organisation reliant on data (i.e. everywhere) that, as in life generally, you get out what you put in (aka GIGO). As the adoption of Agile increases, particularly in an organisation of reasonable size, it is all too easy for strain to appear between management and the developers, whether through the request that they spend time entering ‘management information’ in systems that bring no discernible value to the developer, or through the insistence that they use a particular toolset, selected for its ability to deliver this information automatically.
For the situation where developers are being asked to provide key metrics, tension can be reduced by the developer simply fabricating their metrics for the purpose of getting the job done, thereby keeping both management (“I see data”) and the developer (“I can get on with my job now”) happy, but adding no value to the business whatsoever.
Enforcing tools and processes on the development teams, the second option I mention, produces less harmony, since resistance to the imposition inevitably remains, and delivers about as much business benefit. The reason for this is often that the tools prescribe a way of working, or deliver their functionality in a way that we, as consumers of applications and IT-based services, no longer accept. Put simply, the application is cumbersome compared with the beauty we are becoming used to on our smartphones and tablets, and as such will suffer from poor adoption... or cause much suffering in the process.
Until development is able to use the tools they want, in a way that suits their style of working, and by doing so be generating the data management teams require, tension will persist and metrics will be, at best, fragmented or, at worst, hiding the significant inefficiencies that such disconnection creates.
I'll be posting more on the subject of metrics, trying to understand better what you believe really matters. In the meantime, let me know your thoughts on what you believe is getting in the way of your ability to gain the visibility you need... or indeed let us know that all is well and feel free to share your secret!