Agile is All About Value — why don’t we manage it that way?

I ran this statement through ChatGBT regarding value- How does Agile identify and determine what is valuable?

Key items I got back included:

  • In Agile software development, value is determined by the customer or end-user.

  • One of the core principles of Agile is "Working software is the primary measure of progress." This means that the primary focus is on delivering working software that meets the needs of the customer and provides value to the business.

  • Another important aspect of Agile is the concept of a "minimum viable product," which is a version of the product that has the minimum set of features necessary to provide value to the customer.

  • Overall, Agile teams use a combination of customer feedback, user stories, and a focus on working software to determine what is valuable and prioritize the development of features and functionality that will provide the most value to the customer and the business.

All very valid responses given the plethora of content related to the question.  And each one of them has a major flaw in how most organizations ‘do’ agile, which is that their teams have virtually no engagement with their customer and often have no idea how their work ties to a customer, think about that for a minute.

Most of the organizations that do agile still have antiquated planning processes that were in place long before agile was even a thing.  Projects are still planned up front, and perhaps even worse for value delivery the traditional way of capturing requirements in a business requirement document has given way to lightweight benefits documentation that provides little in the way of value context.

Planning projects up front with established requirements already in place, which are typically gathered by a business analysis group that is the ‘voice of the customer’ means that how the teams working in agile are already disconnected from the customer or user.  Value is lost in vanity statements about benefits and lofty language such as the ‘user shall’ do something.  Though it sounds user-centric, it’s not, and trust me I’ve written, reviewed, and tested off of hundreds of BRDs over the years.

So how should we define value?  From the strategic level, not at the team.  Teams should be delivering incrementally and responding to customer/user feedback to ensure we deliver the best possible outcome for the strategies we want to emphasize.  To do that the organization must define a value model that provides value scores that have quantifiable outcomes.  Teams that understand the expected outcomes will then have a clear understanding of what is expected and how they can design something that delivers upon those expectations.

I have seen too many teams get lost in the excitement of new technology that supports something they think the customer wants, to the point that nothing ends up being delivered or what is delivered is vastly different from what the customer actually needed.  The reality is that customers could care less about the underlying technology of a feature, if you told them it was developed in dbase they simply wouldn’t care if it met their needs.  To deliver the right solution we need to have the value we are expected to deliver clearly in focus, if we develop something highly complex we aren’t likely to meet our value/cost expectations.