An Agile focus on value

Agile Focus on Value – Golden Eggs

If you implement Scrum ceremonies, you are technically doing Scrum, but are you embracing an Agile philosophy? Is your team engaged in productive work valued by the stakeholders? What do we mean by productive?

We will define productivity in terms of value. Value has a broader definition than just commercial value. It also makes the product delivery process more efficient or provides a qualitative or quantitative advantage. This speaks to the philosophy of effectiveness.

What does it mean for a team to be productively engaged in valued work? Agile-speak is wrought with such platitudes. The implication is that work must produce value for the stakeholders. But who are the actual stakeholders, and what does it mean to produce value?

Let’s look at what this means from an Agile/Scrum perspective. We will shape this conversation with the following:

  • A few definitions to establish common ground,
  • A few red flags to help assess if you are going off the rails,
  • Policy check-points to act as guideposts
  • Assessment questions to initiate your team’s conversation.

Who are the stakeholders?

The product owner represents the interests of all the stakeholders trying to predict the behavior of the actual users. However, the stakeholders may be buried by layers of bureaucracy. Customer usage patterns may be difficult to perceive. So is the value determined by those who provide the funding or by current and future customers who use the product? Once we have a better handle on value, a Scrum team may be better able to provide it.

Highly functioning teams

Is your development team just a highly paid order-taker or an integral part of providing a solution?

One of the characteristics of highly functioning teams is that they are engaged in value-based work. They have a clear and aligned purpose. The team understands the objectives of the sprint and how it benefits the stakeholders. They have clearly stated priorities, understand the value they provide to their customers, and are familiar with the value proposition.

The value proposition

The value proposition is a concise statement of the benefits a company provides to customers who consume its products or services. It’s a declaration of intent, both inside the company and in the marketplace. It answers the following questions:

  • What is the brand offering?
  • What job do customers hire my brand to do?
  • Who is my competition?
  • What sets my brand apart from the competition?

Who determines value?

According to Christianaan Verwijs, “value” is a transaction between the Scrum team and its stakeholders.  Is the product owner the final word on value based on interpreting the statements of many stakeholders competing for funding, or the development team just taking a shot at it?

Let’s be clear. It’s not that development teams are the final arbitrator on value; rather, they should be free to discuss the issue.

This is more than just a conversation with the product owner. It includes the stakeholders and management as well. The product owner’s role is similar to the traditional business analyst’s in that they need to gather a consensus from the stakeholders, not necessarily enforce their opinions.

So, is it the stakeholders who determine value? In a greater sense, no.  Their role is to predict their customers’ current and future usage trends.

It’s the marketplace that determines value!

Pain points

Is your team focused on providing value? It’s easy for a team or organization to slip into bad habits. So how do you know your team is going off track? Sometimes it’s only a feeling that something isn’t right. Let’s consider a few pain points.

Red flags:

  • The team finds it difficult to identify the “value” of the delivered feature
  • Work not originating from the stakeholders is requested without explanation
  • Many high-value features are a lower priority than those in the work queue
  • The sprint often crashed without explanation
  • Refactoring the code base is not being performed periodically

Policy checkpoints

Consider establishing a few policy statements as part of your working agreement. It need not be too excessive, just a few statements the team can refer to.

  • The product owner will provide a product goal with the intended value proposition
  • The product owner will provide objectives for the sprint
  • The work performed by the team has an immediate or future value for the stakeholders
  • The team is free to ask questions of the product owner, stakeholders, and management about the value of the work being considered

Types of value

As a starting place for this conversation, I will use and expand on Christiaan Verwijs’s description, which identifies five types of value:

  1. Commercial value
  2. Efficiency value
  3. Market value
  4. Customer value
  5. Future value

Commercial value is that which directly produces revenue. This is the amount a willing buyer would pay a willing seller in a non-regulated environment. These items directly produce revenue. A straightforward type of value is typically the teams’ first consideration when considering value.

Reflect on these questions:

  • Considering the product goal, how does this item increase our revenue or profit? – Christiaan Verwijs
  • When can the team expect an increase in revenue from the product or service offered?
  • Does the new feature lower the price of what’s being offered to the customer?
  • Does the product or service cost more to produce than it’s worth to the customer?

Efficiency value is the ability to do something well without waste to achieve the highest output. It reduces unnecessary resources to produce a given output, including personal time. It’s more than just refactoring the software. One must also consider how the team spends its time and items involving improving the costs associated with delivery, maintenance, and production. These don’t necessarily generate revenue by themselves.

Keep these questions in mind:

  • With the product goal in mind, how does this item save us money or time? – Christiaan Verwijs
  • Does refactoring include attempts to simplify the existing product or codebase into a more elegant or simpler solution?
  • Does refactoring also include platform upgrades or security issues?
  • How can the team increase the efficiencies of their production process?
  • During a sprint, are team members pulled off on side projects, especially those that don’t support the product goals?
  • Are there tools available that can help the team increase their productivity?

Market value is the price buyers are willing to pay or are currently offered for an asset in a competitive marketplace. This value is determined when there is adequate information, both parties are not under compulsion, and they agree upon a price mutually. In this sense, it helps distinguish the product from competing products or helps move it into new markets. From a stakeholder’s perspective, it distinguishes them from the competition. It’s important to articulate to the team the nature of the competitive marketplace they are working in.

Consider the following:

  • With the product goal in mind, how does this item allow us to attract more users or customers?  – Christiaan Verwijs
  • Has the product owner articulated the following:
    • The intended value proposition
    • Who the competition is, and what makes them successful
    • What customers value
    • The strategic significance of what’s being offered
    • How the product or service is being positioned
    • The plan to become the preferred provider
    • The plan to enter a different marketplace
    • A comprehensive list of value elements affecting the costs and benefits offered to the customers
  • Can the team explain how their invested effort provides a competitive advantage for their product or service?
  • Does the product or service satisfy predicted market trends or emerging customer expectations?

Future value is a financial concept that assigns a value to an asset based on estimated variables such as future interest rates or cash flow. In this discussion, the future value is those activities with a future payoff, such as research, innovation, the reduction of technical debt, or test automation.

Take note of the following:

  • With the Product Goal in mind, how does this item save us money or time in the future> – Christiaan Verwijs
  • How new features or technology do the following:
    • Enhance current customer experience
    • Increase the longevity of the product
    • Attract more customers
  • How much time is allowed for the following:
    • Conducting research
    • Providing innovative solutions
    • Reducing technical debt
    • Implementing test automation

Customer value makes the product more valuable and useful to its customers. As Eric Ries says in The Lean Startup, it increases the “stickiness of the product.” Consider features with minimal commercial value that customers commonly request and keep them invested in the product.

“Everything is worth what its purchaser will pay for it.” -Publilius Syrus, first century BCE.

Questions to consider:

  • With the product goal in mind, how does this item increase the likelihood that a customer continues to use our product? – Christiaan Verwijs
  • Are sprints evaluated for customer satisfaction?
  • Can the Product Owner articulate the following:
    • What do the customers value?
    • What is the business value of the sprint or user story?
    • Is there a clear goal or theme for the sprint and how it benefits the users?
    • Why is a feature desirable to the stakeholders?
    • How will we plan to increase customer retention?
    • How will we enhance the customer experience?
  • Do the sprint or user stories often lack a clear business value or stakeholder input?
  • Whose perspective is used in deciding what new features have more value?

Institutionalizing value is embedding value into the actions of the organization. It creates a structure and culture that embeds value in the decision-making process. It empowers people at every creative process stage and creates smarter institutions.

Consider these questions:

  • How does the enterprise ensure value is part of the long-term planning or forecasting efforts?
  • How does the enterprise evaluate customer usage trends?
  • Are milestones and roadmaps reviewed with the team?
  • How is the culture of Agility propagated throughout the organization?
  • Do chat rooms, Lunch & Learn, or lean-coffee sessions discuss the customer experience or their expectations?

Closing thoughts

It helps to assess your team’s current approach to Scrum periodically. In Ron Jeffries’s The Card, Conversation, Confirmation, he proposes that user stories are “social” instead of “documentary” requirements. Consider this an extension of that approach for a question-based, non-linear maturity assessment. It’s more about your team’s discussions on how to offer more value rather than the questions themselves.

Compliance with Scrum ceremonies may seem the obvious first choice to improve your process, but attention to a form without consideration of function will lead to stagnation. It’s tempting to stop there but consider that as the first part of your Agile journey. The next step might be considering how the team relates to the work.

References

Scrum: Novice to Ninja by M. David Green

The Card, Conversation, Confirmation by Ron Jeffries

Five Types of Value, published Scrum.org February 9, 2021, by Christiaan Verwijs Beanstalk Guides Deployment Best Practices 

Harvard Business Review, Business Marketing: Understand What Customers Value

Investopedia, Caroline Banton, Efficiency: What it means in economics, the formula to measure it

Investopedia, James Chen, Future Value: Definition, Formula, How to Calculate, Example, and Uses

3 philosophies that influenced software development, Erica Vartanian, Erica Vartanian 

Investopedia, Value Proposition: How to Write it With Examples, Alexandra Twin

Harvard Business School, Catherine Cote, Value Proposition

How to deal with competition in the marketplace, Team ZenBusiness

What is a competitive market? (Definition and how it works), Jamie Birt

This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They may not represent the opinion or policy of Agile Alliance.

Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks
Donald “Mark” Haynes

Donald “Mark” Haynes

I’m a renaissance man trapped in a specialist’s body. My degree is in biologist. That’s why I’m in IT. I’ve worked as a software developer with an elegant language for a more civilized age. I became a QA guy because breaking things is therapeutic. I became a process specialist because it’s easier to negotiate with a terrorist than a Methodologist. I have been working as a Scrum Master and Agile Coach. I have drunk the…

Recent Agile Alliance Blog Posts

Post your comments or questions

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Not yet a member? Sign up now