Building working software is no longer a problem; delivering value is the challenge.
In February 2001, the Agile Manifesto was born because building working software was a nightmare for many companies. Something had to change, and the manifesto addressed that very well. Although the Agile Manifesto is still relevant to building working software, our current challenge is another. Today, many companies can build working software, but they fail to deliver value. My philosophy is:
Building features cannot ensure value.
Being Agile is not enough to deliver value.
Until teams can focus on producing value, useless software is the outcome.
I believe it’s time to create a Product Manifesto! We cannot keep building features that nobody needs. We need to stop wasting our time. An urgent change of focus is what we need.
A meaningful Product Manifesto could guide product teams on delivering value no matter which framework they work with. At the end of this post, I will share my Product Manifesto draft. Hopefully, you can benefit from it.
Note: The content of this article is based on my experience and observations over the last ten years. That’s why I invite you to share your perspective as well.
The Agile Manifesto is outdated
The challenges we face nowadays are completely different than the ones faced when the Agile Manifesto was written. Mainly, the manifesto focuses on the output while not mentioning the outcome. Therefore, blindly following it will not ensure you deliver value to the users and businesses.
I think the Agile Manifesto has done its job well, but now we need something more to combat our challenges. Allow me to elaborate.
The Agile Manifesto has the following four values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
None of these values have an outcome orientation. For example, a Scrum Team may have meaningful collaboration and interaction with business people and customers and yet deliver no real value. Nor Working Software neither Responding to Change have the assurance of maximizing the value.
To make matters worse, when I look at the Agile Manifesto Principles, I perceive some of them as a feature-factory orientation:
- Business people and developers must work together daily throughout the project. I’ve seen that many times and the result is building something to please business stakeholders while missing the users’ needs.
- I completely disagree with this one. Working software is the primary measure of progress. All features are irrelevant until the end-users can benefit from them. In my opinion, working software can not be used as a progress measurement.
The Agile Manifesto was never updated, though our challenges did. Nowadays, building working software is easier than twenty years ago but delivering value to the end-users is a daunting task.
Jeff Patton shared an interesting perspective on a podcast with Melissa Perri. He remembered that software folks created the Agile Manifesto, and the goal was to help companies build better software. Yet, the product perspective is absent. This part should not be forgotten by those who believe in the Agile Manifesto.
Shifting from working software to delivering value
I am tired of talking about features, solutions, requirements, and roadmaps. From my experience, I’ve learned that it’s easy to focus on what we can plan and execute, and it’s tough to focus on the unknown. That’s why we love planning solutions to implement instead of problems to solve.
Embracing the unknown is exhausting, and yet needed to deliver real value.
No plan can assure producing value. I perceive most of the plans as a waste of time. We plan, analyze, think, rethink, change, adapt, and in the meantime, we don’t deliver anything. The challenge is about learning what works and what doesn’t. Inspecting and adapting a plan is pointless.
I challenge whether organizations are ready to change how they work dramatically. So far, I’ve observed many ‘Agile transformations’ that touch only the execution, meaning that teams do Agile, but management keeps doing business as they did decades ago. Executives define what needs to be done in which timeframe, and they expect agile teams to match their expectations. Yet, they have the audacity of claiming to be an Agile organization.
Are executives ready to renounce their power? Until they can empower agile teams, delivering value is just a wonderland.
To be value-driven requires more than working with any agile framework. No matter which agile framework you choose, no team can deliver real value without having decision power.
Agile frameworks are incomplete by design. For example, Scrum doesn’t cover product management, but it’s the most used agile framework in the world. That’s why many problems happen. Companies often misunderstand Scrum and try to use it solely as an execution framework. Unfortunately, without solid product management skills, no Scrum Team can unleash its maximum potential.
Maarten Dalmijn challenges if a perfect Scrum implementation ensures value. And I am with him; Scrum doesn’t cover critical aspects of how to deliver value. Here is what Maarten said:
Does Scrum provide answers to any of the following questions?, How to create a compelling Product Vision?, How do you come up with an effective Product Strategy?, What is your product?, Who is your customer?, What does value mean for your customers and the business?, How do you arrange your Product Backlog to deliver the most value?, How do you increase confidence that what you’re working on will be valuable?, How do you validate what you’ve delivered actually is valuable? Let me spoil it for you: no. Scrum provides zero answers to any of these questions.
That’s why I long for a Product Manifesto. Organizations will fail until they understand how to deliver value. It’s time to focus on what matters.
Let me share my Product Manifesto draft.
Product Manifesto Values
- Solving Problems over implementing solutions
- Outcome Orientation over defining features
- Hypotheses Validation instead of following opinions
- Empathizing with End-Users instead of presuming their needs
Product Manifesto Principles
- Generating value is the ultimate measure of success.
- Establishing clarity on what value means and what doesn’t is key to success.
- Never start evaluating solutions until you understand the problem.
- Set one priority at a time and say no to whatever distracts you from that.
- Embrace learning by finding fast ways of validating assumptions.
- Leadership trusts the product teams to do the right thing. Therefore, product teams are empowered to make decisions.
- Don’t keep useless features in the product; remove what doesn’t add value.
- Set a due day for backlog items, continuously adapt to what you’ve learned. Remove items when the due date is reached.
- Strive for alignment with stakeholders instead of trying to please them.
- Learn how to differentiate needs from wants.
- End-users feedback matters more than stakeholders’ opinions.
- Define what leads to success, and create ways of measuring it daily.
I need your help to make this manifesto sharper. What would you adapt here and why? Please share your thoughts with me in the comments, and let us transform the digital product world.
Final thoughts
For many years I’ve tried to find better ways of implementing agile frameworks in organizations. I was tired of experiencing Scrum teams becoming feature factories. For now, I believe the challenge is more extensive than implementing agile frameworks. It’s about changing how organizations think. Here are the changes I believe to be mandatory to thrive with agility:
- Stop emphasizing plans. Focus on finding alternatives to learn faster.
- Treat failures as a required step towards success. No failures mean the company is playing safe and missing the chance of innovating. Eventually, the competition will swallow companies like this.
- Don’t treat features as the end. Understand the difference between outcome and output.
- Humility to accept we don’t have all answers.
Customers will never love a company until the employees love it first. SIMON SINEK