Blog Why the Developer Gap Is Really a Prioritization Gap

In today’s digital era, it no longer makes sense to rely on outdated production metrics to determine the value of software development. But how can organizations decide which priorities are truly most important when there are so many competing for these critical resources? In this blog, learn the difference between productivity and value and how to optimize the efficacy of your development team by removing the distraction of unvaluable work.

There’s a shortage, but it’s not developers.

The U.S. Bureau of Labor Statistics revealed a global shortage of 40 million skilled workers worldwide at the end of 2020, 90% coming from a lack of tech experts. This global talent shortage is expected to double by the end of the decade. At the same time, the Standish Group found that “80% of features and functions have low to no value.” This was further validated by Pendo in 2019, in findings that “80% of features in the average software product are rarely or never used.” These findings are in direct parallel with the Pareto Principle (also known as the 80/20 rule), which states that roughly 80% of outcomes come from 20% of inputs. The Standish Group even determined that in some cases, less than 5% of a packaged application’s features were being used.

From this research, we can conclude that the software development your organization is currently working on may likely add little to no value. In the place of value, we find a massive waste of overproduction (one of the eight forms of waste in Lean), therefore wasting valuable financial resources. This problem is compounded by modern development writings that promote practices and tools to do twice the work in half the time.

It is not uncommon for organizations to be oblivious to what they are prioritizing. This often results in a process called passive prioritization. Even if an organization has a clear prioritization list, there are likely competing priorities (often of lesser importance), too many priorities and lack of governance when it comes to working only on items that align to their priorities. To quote Stephen Covey, “Most of us spend too much time on what is urgent and not enough time on what is important.” Covey also states, “When you have too many top priorities, you effectively have no top priorities.”

Historically, organizations measure productivity.

When creating software features and functions that generate value, the problem becomes much more systemic and hereditary. For most organizations, it is less about how they are prioritizing their work and more about what they are prioritizing. During the second Industrial Revolution, organizations grew in scale due to new technological advancements, new sources of power, and revolutionary inventions for both communicating and transporting over increased distances. This was the age of organizational models of production and mass-production assembly lines. Therefore, it was natural that in the production era organizations measured their effectiveness with production metrics. Metrics like Parts Per Person Per Hour (PPPH) worked because demand outpaced supply and competition was low.

In the digital revolution (our current era), recent supply chain shortages aside, we have attained mass production. Consumers are inundated with options to the point of decision paralysis. There are even dozens of options for competitive intelligence tools to better analyze your competition’s marketing, sales, customers, etc. Furthermore, industry disruptors are constantly being discovered with advancements in technology (for example: Augmented Reality (AR) in the beauty industry). Additionally, digital content has different constraints than material goods, such as not having to reproduce an application for every person who wants to use it. It is no longer in your best interest to rely on production metrics for your organization’s survival. And yet, we see organizations time and again relying on the antiquated metric of PPPH in their digital organizations. More commonly this can be recognized as Points Per Person Per Sprint (PPPS) aka velocity. Or even worse, companies that assume because a project is on time, on scope and on budget (The Iron Triangle) that it was a successful and ultimately valuable project.

Productive work does not equal valuable work.

This is not to say that production metrics (often referred to as outputs) have no place in software development. There are key metrics that have been recognized for reliably measuring software delivery performance, such as lead time, deployment frequency, mean time to restore and change fail percentage. However, our first bottleneck to delivering profitable software is ensuring that the code we are developing is actually valuable, not simply that we have developed it quickly, efficiently or in a sustainable way. Likewise, the Theory of Constraints (ToC) instructs us that there can only be one true bottleneck, and therefore any changes outside of that bottleneck are ineffectual. The first principle of the Agile Manifesto even tries to warn us of this by declaring that “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” This means that the number one measured priority should be that the software is valuable to customers. This priority should be accomplished through continuous delivery practices. Continuous delivery practices are not the end goal, or the top priority, and therefore using metrics that measure our effectiveness to continually deliver distracts organizations from their true top priority, valuable software.

The challenge with measuring value is not only in defining what the word value means, as Mark Schwartz so effectively ruminates about in his book “The Art of Business Value,” but the fact that it is as unique as the customers, products and organizations themselves. To understand what you should be measuring, determine why your organization or product exists. Why would customers want to use your product, service or system? And how is that financially beneficial to your organization? The products you develop must be desirable, feasible and viable. This means that, at a high level, there are two types of value we are concerned with: customer (desirability) and business (viability). The constraint to those two being feasibility — can we actually accomplish this feature or functionality with a reasonable investment?

Measuring the right priorities takes the right experts.

How do we determine if something is desirable? There is an entire industry dedicated to this — User Experience (UX) — and the multidisciplinary field of study known as Human-Computer Interaction (HCI). This area of expertise combines computer science, behavioral science, cognitive psychology, human factors and more. If we have learned anything in the 60 years since Margaret Hamilton coined the term software engineering, it is that people struggle when determining what is valuable to other people. Therefore, we have experts trained in science and research to help organizations discover what is desirable to their customers. Remember the 80%+ of unused features from the beginning of this article? Well, if your organization leverages UX effectively, then you could potentially clear out that 80%+ of your development pipeline before it ever reaches your developers.

Imagine a future where a product manager is vetting the viability of a solution before it is ever developed, and an architect, engineer or team of developers is estimating the viability of your feature or functionality. Now your organization can make an educated decision based on the perceived value, estimated cost and forecasted revenue. You could even map those items out with an impact map or prioritize your work utilizing a business value framework. This is the path to leveraging the tenth principle of the Agile Manifesto: the art of maximizing the amount of work not done. After we have removed the distraction of unvaluable work from your developers, we can optimize their delivery efficacy by another 35% with proper tooling and development practices alone.