“Double Whammy” is defined as a “two-fold blow or set back”. The first “whammy” is that according to McKinsey, only 5% of executives understand that for high performing teams, collaboration and DevOps tools, are the number one contributor to achieving a 5 fold revenue improvement (see the chart below).
The second whammy is by inference, (and courtesy of our own research and ten-year experience), that the bulk of the money is being spent on less important functions and not ones that have been proven to directly lead to business/growth based performance improvement.
Of course the folks that manage and nurture the tools/systems get it. The suspicion this brings is that it just isn’t being sold very well. Please note we’re not saying ITSM isn’t important, just that the ROI isn’t anywhere near as compelling as Agile support, dev ops and collaboration.
The research in question by McKinsey & Company is entitled “Developer Velocity: How Software Excellence Fuels Business Performance”, in which they discuss the results of a study conducted on how software development impacts businesses. It is a fascinating piece – the full link is below. The net-net of it is that once teams reach a certain maturity point, one of the key, if not the most important factors, is the quality of the tools being used.
McKinsey measured developer velocity via their Developer Velocity Index (DVI), a comprehensive view across 13 capabilities and 46 performance drivers; including the empowerment of developers, removing points of friction, and creating the right environment to innovate. This makes sense. As a side note, “velocity” in Agile terminology is a different but related concept, its a team specific metric of the scope of work a team can deliver during the course of a sprint. It’s usually expressed as the measurement of the complexity of a story with typically a Fibonacci series. In this model you can’t compare teams as each team has different capabilities. In any sprint, the velocity of that sprint is the sum of all story’s points that are fully completed and signed off by the product manager.
The Study
For the study, McKinsey talked to tech executives at 440 large companies, over 100 CTOs and CIOs, and many senior engineers in those firms, and got them to rate their companies’ performance in several areas to determine their developer velocity. The results are staggering, and important to highlight.
Those companies in the top 25% for developer velocity showed 60% higher shareholder returns, 20% higher operating margins, and were significantly more innovative in development. The top performers also scored highly in all the categories that McKinsey sees as the key contributing factors to developer velocity: tools, culture, product management, and talent management.
Above all else, McKinsey states that utilizing best-in-class tools are the top contributor to business success. Using the best tools allows for greater productivity, visibility, and coordination across teams.
One of the key insights from this study is just how many business leaders misunderstand the critical factors in developer productivity and success. They note that many of the executives they spoke to believed that increased agile processes at the team level would be one of the best ways to lift performance, but the results of their study showed that agile practices only helped lift performance among the lowest 50% of performers and that beyond a slight performance bump, those processes do not contribute highly to developer velocity. The key takeaway from their section on the common misconceptions of leaders is this thought: “the underinvestment in tools across the development life cycle is one reason so many companies struggle with ‘black box’ issues”.
In wrapping up their article, McKinsey provides four recommendations for increasing developer velocity. Empower developers with world-class tools (organizations with strong tools are 65% more innovative!), create a culture that fosters psychological safety (i.e. ability to try and fail, learn and improve), create a comprehensive product-management function, and focus talent-management on the developer experience. If you follow these tips, you’ll be well on your way to improving your company’s software development performance..
Companies that excel in providing the right tools, culture, product management, and talent management not only develop software faster but also deliver significantly stronger business outcomes.
The Second Whammy – Compounding the Failure to Invest in Tools for Development
Our own research shows that to further compound the issues with underspending on Development and collaboration tools, organizations have been overspending on siloed systems, especially in ITSM plus Portfolio and Project Management (PPM). The “supposed” leading vendors in ITSM for instance are charging a multiple of 5 to 1, versus spend on Developer velocity based investments. Although anecdotal, we believe that the trend to Agile is over-hyped as a complete phenomenon and that waterfall development still accounts for over 50% of projects in many large corporations today.
The spend on traditional/legacy portfolio management tools, plus related accounting control systems, far outstrips spending on dev ops and collaboration. In the end, these stand-alone solutions further hinder performance because they operate independently from any idea that there should be a shared platform from which velocity is derived. We are not saying that these other processes aren’t important, what we are saying is that they don’t deserve a premium and they certainly don’t deserve to reduce spending on critical developer velocity drivers. A good example is that support tickets through an ITSM platform, if they need to be fixed by development, need to seamlessly flow into a developer’s backlog. If ITSM is cordoned off from the Dev tools you immediately have issues with “flow” across the organization.
It would be remiss of us not to mention the final nail in the coffin; training. It is supposed that Agile teams and developers are fast learners and can learn new tools via internet videos. With regard to more complex Agile planning and dev ops integration however, this is not the case. So often we have heard complaints about Jira and Confluence – its hard, it doesn’t do this, it doesn’t do that. Yet upon closer inspection when asked how much training did you receive on best practices and Agile adoption via the tools, the answer so often is DIY.
Do you know your own Value Added Ratio (VAR)?
In conclusion, ask yourself this – let’s say you have a staff of 300 working on development-related work. That team is costing you conservatively $22M a year or about $2M a month. Do you know exactly what your value-added ratio is? This ratio is time spent directly on value-added product build activities vs non-value added work e.g. administration/company meetings etc. Simply put: making products makes money. Because Agile is focused on work only aimed at improving VAR, this becomes one of the most critical measures to determining Dev and team performance. Tools are the only way to obtain this data consistently across teams.
If your timesheet tools are directly tied to the task and story level (the value add) then this is easy to calculate. If your timesheet system is stand alone and concerned more about budget and cost management, you have lost the battle straight out of the gate. The crazy thing is that the timesheet system probably costs you a lot of money…. (and by the way, did you know that some of the fast-growing 3rd party apps in the Atlassian ecosystem are time management based?). Why do you think that is?
If you are looking to improve your development velocity, at Blended Perspectives we can show you how Atlassian provides those exact world-class tools and training you need to support world-class software development. We also have some great ROI calculation tools to directly tie your spend to cost savings and value-added business performance. So give us a call!