To deliver value, understand It
Value is a frequently used term in the agile software world. In fact, it is prominent in the first of the twelve agile principles :
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.Understanding what value is, how it's generated, and how to maximize value is difficult to understand. To shed light on this topic, we'll examine models for explaining value generation and explore how to ensure value is being delivered.
What is Value?Value is anything that the organization wants. It takes a variety of shapes from user retention to market share to page views. Because of this open-ended nature, value seems to be in the eye of the beholder. And there are lots of beholders on software projects: developers, product managers, testers, executive sponsors, end users and the list goes on. This can lead to the perception that value is subjective. That isn't the case. Value can, and should, be measured, analyzed, and monitored. Assign metrics and success criteria for the project and record data throughout the lifecycle of the software. In the end, only those who deliver value survive.
The Dude’s LawInspired by Ohm’s Law , the Dude’s Law is a simple model for explaining value. It was created by agile speaker and coach David "The Dude" Hussman.
Value = Why / HowV = W / H , where V is Value, W is Why and H is How. If Why is constant and How is increased then Value is reduced and when How is decreased Value is increased. For example, if the Why is the eradication of poverty and starvation, a massive expenditure of resources and even realignment of economic and government systems can be done and still achieve a great value. Despite the gargantuan How in the denominator, the Why is so great that a large Value is still delivered. If the Why is simply to deliver a sandwich to the author and eradicate the author’s current hunger, it doesn’t make sense to have a massive expenditure of resources and realign economic and government systems as the Value delivered to society, one less hungry author, is far too small given the Why. Let's examine each component in the equation.
WhyThe Why is the reason for undertaking an activity. For the most part, the Why is the constant in the equation. At any moment, it's difficult to change or increase the meaning of the activity. However, situations arise where the Why may change over time. For example, a microservice’s Why may increase as its use by other services increases.
HowThe How are the mechanics or processes used to achieve the Why. Using Dude’s Law, it becomes clear the more How needed to accomplish the Why, the less Value received. This means the How must be simple, lightweight, automated, error-resistance, scalable, maintainable, and replaceable.
ValueValue is the result of dividing the Why by the How. This means applying mechanics and processes in proportion to the Why. Too large a How for a small Why risks not delivering Value. Are you applying the right How for your Why to achieve maximum Value?
The Vision Execution Value CycleThe Vision Execution Value Cycle is a model showing how we strategically align teams and organizations to provide value. And how this value leads the creation of further value. A vision describes how the organization can better themselves and their stakeholders. Acting upon the vision generates value for the stakeholders and organization. Examining the value created, refines the vision. The new vision seeks to maximize the value of existing work, capture new value where gaps exists, or change directions. At a macro level, the cycle describes a business doing strategic planning for the next year. At a micro level, the cycle applies to a development team doing continuous delivery and getting fast feedback from tests and users. A lack of vision will result in waste in the execution phase and poor delivery of value. If the organization lacks the ability to deliver there will be a reduction of value. Let's examine each component of the cycle in further detail.
VisionThe vision is a concise statement describing the purpose of the initiative and the expected outcome. Strategy is formed and goals are created from the vision. A good vision has the following characteristics (R. Pichler, Agile Product Management with Scrum: Creating Products that Customers Love . Addison-Wesley Professional. 2010):
- Shared and unifying - everyone buys into the vision from the implementation team, executive sponsorship, management, to users.
- Broad and engaging - the vision is inspiring and guiding, but leaves enough room for creativity and flexibility in developing a solution.
- Short and sweet - the vision should only contain the information critical to success.
ExecutionExecution is what turns a vision into value. A solid vision plus a solid execution is worth more than poor vision and poor execution. Derek Sivers describes this idea in the book Getting Real (37signals, Getting Real: The smarter, faster, easier way to build a successful web application . 37signals. 2006):
To me, ideas are worth nothing unless executed.They are just a multiplier. Execution is worth millions. Explanation: Awful idea = -1 Weak idea = 1 So-so idea = 5 Good idea = 10 Great idea = 15 Brilliant idea = 20 No execution = $1 Weak execution = $1000 So-so execution = $10,000 Good execution = $100,000 Great execution = $1,000,000 Brilliant execution = $10,000,000 To make a business, you need to multiply the two. The most brilliant idea, with no execution, is worth $20.The most brilliant idea takes great execution to be worth $20,000,000 .To execute well, an organization must have the capabilities to do so. Capabilities include employee skill, process excellence, time to market, production capacity, and more. An honest assessment of your capabilities may lead to retooling teams, hiring, or bringing on outside help.
ValueValue is the outcome of applying an execution to a vision. The value generated influences the next round of strategic thinking. Use feedback from stakeholders and users to inform decisions. But don't forget objective measurements using metrics based on success criteria. Create a new vision and starts the Vision Execution Value Cycle all over.
Building for SuccessAs Tom DeMarco famously wrote in Controlling Software Projects, Management Measurement & Estimation , “You can’t control what you can’t measure.” To make sure value is being delivered, we must measure it. The first step in measuring value is determining what we value. With this identified, we then need to determine what metrics we will track. Finally, we set success criteria to determine if we are getting enough value out of our work. Chances are you value a number of different things with your software product. List them out. Then take a hard look at that list. What do you really value? Prioritize the list. This will help you determine which features to work on first and which can be delayed. For each value, determine how you will measure it. For example, these measurements could be performance related, end user surveys, or sales and conversion numbers. Determine if you have the capability to gather that data for each measurement. If the capability doesn’t exist, start adding stories to your backlog to fill those holes. Data collection is a key component of your product. Success criteria uses the measurements and sets an objective standard for what success looks like. For example, a decrease in monthly cloud vendor costs by $1000 or average time in the checkout decreased by 10 seconds. With this in place, we can adopt hypothesis driven development (HDD). HDD is a way of developing new products and services based on the scientific method. In the scientific method, we observe, form a hypothesis, test the hypothesis, and evaluate the results of the test. HDD uses this idea to ensure changes introduced into a product produce value. Describe each new feature or capability using the following template:
We believe that <this change>, will result in <this desired value>. We will know we succeeded when <this success criteria>.For example, if I am running an e-commerce site one thing I may value is the conversion of items added to a cart to sales. I may write the following HDD scenario:
We believe that providing a one-click checkout button inside the cart, with a default saved payment method and shipping address, will result in less abandoned carts. We will know we succeeded when we see a 5% decrease in abandoned carts per quarter.If the change achieves the desired value, great! Form a new hypothesis and capture lightning in a bottle again. If the change fails to capture the value desired, iterate on the idea until the desired value is captured or back out the change. Remove poor performing changes to keep the software clean, maintainable, and easy to introduce future changes. Each line of code added has a significant cost when it comes to keeping the code maintained, tested, and healthy. There is no reason to continually pay this cost for poor performing features. We can all probably name a software product we used to love that died a slow death due to feature bloat. To keep poor performing changes from significantly affecting your product, consider A/B testing or a canary deployment. If you’ve never done something like this or don’t have your infrastructure set up to handle such a thing, let’s talk. Pythian can get you there.