Share this
by Russell Shurts on Feb 23, 2018 12:00:00 AM
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 Law
Inspired 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 / How
V = 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.
Why
The 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.How
The 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.Value
Value 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 Cycle
The 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.
Vision
The 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.
Execution
Execution 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.
Value
Value 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 Success
As 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.
Value Delivery
Imagine for a moment you’ve been assigned three tasks. They are of equal importance and will take approximately the same amount of time to complete. Upon completion of a task you will be paid a large sum of money. What’s the best way to structure this work?
Visualizing the problem leads us to a clear conclusion. If we value getting paid, we should focus on one task at a time. The more we divide our attention between the tasks, the longer it takes to capture what we value.
Unfortunately, many software projects are run using scenario A. Each task is instead a feature of the software product. Scenario A describes an approach where work is divided at architectural layers. All the necessary infrastructure is set up for all three features, database work is done, then backends are written, finally the front end is coded, tests are performed, and features are deployed. It takes the entire project span to see the value of the features.
Work needs to be organized around capturing value, this is known as
vertical slicing
. As a result, we focus on delivering features. Each feature must contain the just the necessary infrastructure, data, development, and testing to ship the feature and no more. Drawing on agile software development and lean manufacturing principles, this way of working eliminates waste and maximizes value.
Of course vertical slicing is only one side of the delivery coin. The other is the process of shipping code and making sure it stays up and running. Here techniques like continuous integration (CI), automated testing, containers, distributed systems, and cloud native come into play. And documents like
The Twelve-Factor App
and the
Reactive Manifesto
help guide the way. Combining these approaches results in high-available continuously delivered software products.
Adopting this vertically sliced, continuously delivered mentality provides many benefits. One, we capture value sooner, which is what we want for building the product. Two, we can have a faster feedback loop which allows us to change direction with less wasted effort. Three, we aren’t handcuffed by architecture and design decisions made at the start of the project when we know the least amount of information. And finally, we are able to measure progress through software in production rather guessing when things will be complete.
Don’t leave value uncaptured. Delivery frequently. Find out how Pythian can help.
No Comments Yet
Let us know what you think