Delivering Value to Customers

Something that has stood out to me in most of the organizations I’ve worked for is a high degree of inefficiency, both at a technical and process level. In my last post, I mentioned that, although I dislike bureaucracy, I’ve come to understand its necessity and the problems created by excessive avoidance of it. However, I am an optimizer by trade, and so when I see inefficiencies, I feel compelled to lessen or remove them. Much of my focus, and the topic of conversation I often bring up when talking to executives, revolves around speed of delivery. The natural follow-up question is: how do we achieve this? I typically provide answers that are specific to the organization’s problems, but now I’d like to outline my general philosophy behind it.

Every company proclaims some variation of “we value our customers” and of course, they must. Customers are what an organization depends on to survive, so if I were to declare, “delivering value to customers is our number one priority” to company leadership, everyone would smile and nod along. If we weren’t doing so, our entire purpose as software developers would be rendered irrelevant. However, it’s important to consider what delivering value to customers truly means. Delivering value implies that a change was made to the application that either helps a customer solve a problem they couldn’t before, or it improves their ability to solve one they already are dealing with.

The implication of this is that any change that does not provide value to the customer is waste. Therefore, we should optimize our ability to deliver maximum value to customers. It may seem like I’m stating the obvious – it might be comparable to saying that success in basketball involves scoring the most points, but it’s quite surprising to find that this core principle, whether in business or in sports, is often forgotten.

What truly matters are the outcomes, not the output. Releasing many changes to customers does not necessarily mean that value has been added. Our industry may have moved on from horrendous measurements like lines of code produced, but as soon as the sole focus shifts to story points and JIRA tickets, we’re right back where we started.

Nevertheless, our primary concern should be building the right thing rather than delivering it quickly.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

– Agile Manifesto

Neither I nor the Agile Manifesto discuss speed of delivery as a priority. This is not because speed of delivery doesn’t matter; it does, but focusing on it detracts from our primary goal of delivering value and shifts the emphasis towards merely delivering code. In other words, if we maximize our ability to deliver value, we get the speed for free.

Developers will work as fast as they are able, as long as they are unconstrained. Therefore, I believe that the best approach for software development teams and organizations is to maximize their ability to deliver, while minimizing their constraints for doing so.

Enter Lean

These ideas have piqued my interest in exploring Lean and its origin, the Toyota Production System. For my next posts, I’m going to explore further, as I believe there is much to uncover there.

Whether in business or basketball, success hinges on superior fundamentals. I believe that understanding these foundational elements is critical for the success of teams and organizations.