The Agile Manifesto, in my opinion, is a decent document. By no means perfect, but still pretty good. I happen to interact a bit with a few of the principles on social media, and I get the sense that if they had written the document today, they might use different language in some places. But I could be completely wrong about that. Nonetheless, the Agile Manifesto is a pretty good and useful document that anyone interested in Agile should pay close attention to. (Many close “Agile” friends disagree with me on this point – they are all wrong).
Why should we pay attention? Because I believe that wrong, yet popular, interpretations of certain principles leads to some confusion. Case in point, most people I speak with, would have you believe that an Agile principle is “we deliver value.” That sounds like something any reasonable person would want to do. Never mind that the concept of “value” is a bit nebulous. Ron Jeffries, in his book, The Nature of Software Development, defines value as “what we want.” Well, who is “we”? Mark Schwartz, in his book, The Art of Business Value, makes the case that business value can be tricky to define. (Both great books by the way. If you don’t you own a copy; I’m not sure what you’re waiting for!)
The point is that value is hard to define. Value might not even be a fixed target. You know, complexity, double-loop learning, and all that jazz. For example, in an Enterprise IT setting where team members develop internal tools for other team members to use as part of the business processes, how would you define value? Where is the value created? When is it created? Who is the value created for? All great questions that require answers if we’re going to walk around telling people we “deliver value.”
But here’s the catch. The Agile Manifesto says something slightly different from what I hear people say. This is what Principle Numero Uno says:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Wait a second. Valuable software? Hmm. Is value shorthand for valuable software? Is that what people mean when they say they delivered value? Is that what you mean when you talk about value? Not in my experience. I think people have grander aspirations than valuable software. I think they’re thinking outcomes and impacts. I’m thinking it too. In fact, I’m not just thinking about it, I’m writing about it. I want the software I develop to help my organization achieve desired outcomes and have the intended impact. But does software have to create value (whatever that is) before we consider it valuable?
In my opinion, valuable software is software that people find useful or helpful. It’s software that is important. It’s software that makes those who use it more effective at their jobs. It’s software that’s beneficial to the organization. (Yes, I did use synonyms of valuable). It’s software that addresses the needs of the stakeholders. We know our stakeholders, right?
Valuable software may not always (at least not immediately) create value (desired outcomes and impacts) because value is impacted (excuse the pun) by many variables, many of which have nothing to do with software. In other cases, valuable software delivered is not intended to create value (as we often define it). And yet in other cases, connecting software delivered with value is near-impossible or at least extremely difficult.
Just because we can’t easily tie software changes to business value doesn’t mean we shouldn’t care about outcomes and impacts, we should. Our processes should give us confidence that our valuable software will eventually create value. But we can’t wait till it creates value to consider it valuable, can we? I don’t think so.
So what do we do in the meantime? I suggest we focus on delivering valuable software.