Chief of Staff: “Gentlemen, the C-Suite is ready for you now, step in this way. And, I hope you have a solid plan. The finance team just laid out a stunning 18-month roadmap.”
CTO: “What? Uggh! We just got these jobs last week. Nobody told us to have a plan.”
CIO: “I have to go in there now and get skewered. What am I supposed to say?”
CTO: “Just tell them…if they hire more developers, all their wildest dreams will come true!”
CIO: “Ok, thanks Napoleon, let’s do this.”
Nobody is under any illusions that software is the basis for competitive advantage in the current age. Software (or the five tech superpowers, to be blunt) has been eating the world for some time. “Those who master large-scale software delivery will define the economic landscape of the 21st,” emphasizes Dr. Mik Kersten in his book, Project to Product. No kidding: in the last year, the pandemic-induced digital-first economy has made “the big five” (Amazon, Apple, Google, Microsoft and Facebook) even richer, with a combined revenue of more than $1.2 trillion.
In response, many traditional “non-tech” organizations are panic-hiring developers to make up ground, with the global developer population expected to reach 28.7 million people by 2024. Hiring more developers, however, is a classic case of hoping for a simple solution to fix a complex problem. Unfortunately, to paraphrase Napoleon Dynamite, expanding your developer roster will not make your wildest dreams come true. Despite increased investment in their teams, many are not seeing the ROI they expected. Product delivery is still too slow, or in some cases even worse than before. For software industry stalwarts, this outcome is inducing a sense of déjà vu. We’ve been here before.
Throwing developers at a problem has been going on since the early days of software delivery. In fact, Fred Brooks, winner of the Turing Award and one of the pioneers of software development team organization and practices for large scale endeavors, literally wrote the book about it back in 1975. In short, trying to speed up projects that were running late by adding developers is an exercise in futility. Known as “Brooks’ Law”, its core message still rings true today:
- Adding developers/people to a late project will make it later
- Development tasks that are not partitioned will not benefit by adding more developers
- Gains made in getting things done by adding more developers may not exceed the additional time demands for communication to/from the additional developers
Adding more hands to fix problems sooner is a false prophecy. This “solution” actually introduces more complexity that slows things down. Existing team members are pulled away from their current work—such as working on a product for a customer—to spend time onboarding new team members. A growing team also means more communication overhead; again, time not working on the product.
Development: Only a Small Portion of Building Software
Worse still, the actual thing slowing down product delivery is not the development team. In my experience, most wait time or waste is further upstream. Take leading U.S insurance company Nationwide: when they start applying value stream management (VSM) thinking to their DevOps pipeline. In applying VSM thinking—i.e. looking at all work from customer request through to delivery—they calculated that out of 120 days to deliver a feature to the customer, only 2.5% of that time was actual development time.
It’s revelations like this that make you realize why VSM is becoming the de facto way to master software delivery at scale. It encourages us to focus and measure end-to-end so we can determine where the impediments to our customer response really are. As John Willis, Senior Director of the Global Transformation Office at Red Hat, co-author of The DevOps Handbook, puts it: “Measuring only one area of the value stream is like only using two inches of a 12-inch ruler.”
Don’t Overburden Your Teams
VSM thinking also ensures you don’t waste time or money on building unnecessary features or fixing a problem that isn’t there. In a recent and inaugural report by the Value Stream Management Consortium (VSMC), which surveyed technical and business professionals, the findings showed that:
- 47% of software developed has no measured business impact
- 67% of respondents either didn’t or rarely measured the actual value realized by new features in their product
- Only 53% of respondents said they do measure business results
This builds on what we’ve known for many years: that there are very high and worrying levels of waste in software work. A 2018 Pendo report found that 80% of features are rarely or never used (equating to $29.5 billion a year in assets being squandered). VSM encourages us to go back to basics and ask ourselves why we are building a software product and for whom. This customer-centric approach helps us think about how value is flowing and determine whether it is actually improving how we operate and innovate, as well as helping us tackle the real problems slowing customer response down.
We can build a better diagnosis of the issues at hand if we measure end-to-end and focus on how value-creating and protecting work traverses from ideation to operation. Instead of knee-jerk reactions of throwing more developers and technology at a problem, in a hit and hope attempt to “go faster”, we should look to understand what is impacting our existing teams first.
One of the most common problems is too much WIP, which reflects an imbalance between what the business wants vs. what the product teams can deliver within their means. If teams aren’t waiting for approvals or clearer requirements from the business, it’s most likely they’re being overloaded with requests. And, hence, a tendency to add more developers. Back again to Brooks and VSM. Do we really understand what is holding us up from delivering better?
In a time when burnout is at an all-time high—83% of developers in the U.K. reported that high workloads and inefficient processes are contributing to coder exhaustion—it’s paramount that we take steps to protect and support our teams. The State of DevOps reports have long extolled the correlation between job satisfaction and organizational performance, that “happy cows make better cheese”. A more recent study found that when Google invested more in employee support and employee satisfaction, productivity rose by 37%. We need to create a culture of lean-thinking continuous improvement coupled with a high degree of customer centricity and respect for people. This is key to not only retaining talent but attracting them, too.
Track Impact, Cultivate Culture of Continuous Improvement
Once you’ve begun to identify where the real wait times, waste and overcapacity issues are, you can begin cultivating a thriving, highly engaged, and highly productive set of teams. And by truly understanding where work is flowing (and where not,) you’ll realize a confident and data-driven approach to making improvements in a manner that will challenge the old and trouble-laden “just hire more developers” approach.
