Twenty years ago, an agile rebellion started among a small pocket of besieged software developers. Today, the benefits of agile methodologies have improved stock trading, federal bureaucracies, and even celebrity chef-led humanitarian efforts. Yet Agile has started to lose favor and be seen as a tool for control rather than empowerment. This has prompted us to get back to basics and start a series focusing on the Principles of Agile.
Let’s start with Agile’s first principle, from the Agile Manifesto:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Just one sentence, but wow is it densely packed!
Starting at the end, don’t misconstrue the phrase “valuable software” as throwaway feel-goodery. Valuable software is the guiding star to satisfying the customer. “Valuable” simply means return on investment. So for every dollar spent, how much value is returned to the customer?
It doesn’t have to be a monetary return, but it has to advance the objectives of the organization. Some examples of value which software could create are:
- Increasing revenues
- Boosting efficiency
- Improving customer or employee satisfaction
- Protecting vital resources
Need more real-world examples? Chamath Palihapitiya highlighted one about Amazon Prime as it pertains to time saved of its members.
Some amazing takeaways from @JeffBezos annual letter:
1) 28% of purchases on $AMZN are completed in less than 3min (!!).
2) 50% of purchases on $AMZN are completed in less than 15min.
3) Research suggests going to an offline store to do the same task takes 1 hour.
— Chamath Palihapitiya (@chamath) April 16, 2021
6) There are 200M Prime subscribers which means these consumers are re-capturing $126B of value for themselves each year.$AMZN Prime captures more value PER YEAR for users than most companies are worth.
At $1.7T, $AMZN trades at 13x their annual value to Prime users.
🤔
— Chamath Palihapitiya (@chamath) April 16, 2021
Prime actually hits multiple categories through increased revenue for Amazon, boosted efficiency of their employees and customers, and it leads to higher customer satisfaction.
Sure, Prime isn’t a classic piece of software, but it is hard to argue that the product is not the culmination of many technologies, massive automation, and yes! lots and lots of software. Providing value is the lifeblood of software and its ongoing development. Software which isn’t creating value lives on borrowed time.
Always Be Delivering
The first principle of agile emphasizes that valuable software comes through continuous delivery.
One of the great differences between software and most other goods is the idea that it can be quickly improved through this “continuous” delivery process. Cars and refrigerators are harder to continually deliver improvements. In fact, almost all improvements to those type of products come through product recalls. Simply clicking “Update” or refreshing a web page can deliver new features, improved interfaces, or add integrated external systems.
In their seminal 2011 book “Continuous Delivery“, Jez Humble and David Farley state that:
Continuous Delivery is the ability to get changes of all types — including new features, configuration changes, bug fixes, and experiments — into production, or into the hands of users, safely and quickly in a sustainable way
Jez Humble and Dave Farley
While the methods and media have changed over the last twenty years, these are the principles that have endured.
At Simple Thread we like to say that great software isn’t perfect. That’s not a free pass to sling bad code, it’s an opportunity to approach building products from a point of humility. Great software can never be “done.” If we hold to Conway’s Law, then if users and their business needs change and evolve over time, so too must the software.
Delivering software once, without the opportunity for fixes, customer feedback, or any improvement means that it will degrade over time — a condition referred to as software rot.
The Early Bird
Why does delivering early matter? Early is the defining characteristic of a minimum viable product. It ensures that the product team must constrain effort and prioritize what the most valuable parts of the application are that they could build. Once parts of the application are designed and built, teams can quickly get feedback from product owners and users. Then teams can know what fixes, new features, or other changes must come next.
This graph from our Bootstrapping A Digital Product publication demonstrates why getting early feedback can lead to better results and more value created from early on.
What happens if a product waits and waits and waits to be deployed (orange line) to users? Then lots of opportunity for feedback and refinement (blue line) is lost along the way — not to mention all the value that is created on the journey (the space between the lines) along with a more rapidly improved product.
Conclusion
There’s a reason this was picked as the first principle, it is of the utmost importance to remember in building software. In the midst of a large project, it’s easy to get focused on the process. Are we hitting deadlines? Are we on track with the budget? Are we incurring technical debt? And so on. These are all extremely important questions. They matter to us. They matter to our clients. However, they are not as important as this first Agile principle.
If we are not delivering valuable software and adapting to customer feedback, it doesn’t matter how expertly it is crafted or how on schedule we are. Or to borrow Laura Klein’s pithy phrasing: if you’re not building the right thing, it doesn’t much matter if you’re building the thing right.
Valuable software comes from establishing customer feedback loops through early and continuous delivery.
Loved the article? Hated it? Didn’t even read it?
We’d love to hear from you.
