I have witnessed many Agile teams not reaching their full potential. They got better and better at creating product increments regularly and improving on this.
These Agile teams typically missed most of these:
Teams work on a piece of functionality but don’t know what their product is exactly. At best, teams know the boundaries of their product feature or product component.
Teams work in silos. Every team optimizes the delivery of their piece, but how the pieces fit together is unclear.
Teams consider it a success when they create output regularly. They don’t take the desired outcome into account.
Teams use predetermined assumptions of value as the truth. They don’t verify if the true value they helped create confirms their assumptions.
Today, I will explain how to turn this around and put the value of the product centre stage.
From project to product
For years, the standard way of working to build a product was to create a design and then plan and execute the product improvements based on the design. Product improvements were planned and executed as a project.
This specific issue did not go away with the introduction of Agile. Agile brought adaptability. But most approaches, including Scrum, still were based upon a backlog of items ordered in a certain priority. The order could change. Items could be added or removed. But it still was a list of things to be ticked off. Most Agile Teams use the backlog to run their projects.
Many Agile approaches evolved. Scrum for instance now focuses on the desired future state of the product (with the Product Goal) and the desired state of the product at the end of the Sprint (Sprint Goal). I consider this as a pivotal step in the evolution of Scrum. The product truly has become the focus.
Having said all of this, many organizations are still project-focused instead of product-focused. To turn this around, they should establish what their product actually is and what they wish to achieve with their product. This then will determine what they should focus on.
Organize around your product
Small self-organizing teams run the risk of being siloed. And missing the overall picture. Many Agile teams have no clue what product they are working on. They know they are part of the back office team, the fraud team or the reporting team. They may have a rough idea of the product as a whole, but often not where the product starts and where it ends. This makes it difficult for the people in the teams to help maximize the value of the product.
But there’s more. Even if all Agile teams would have a way to collaborate on the product as a whole, they only focus on the core product. Mostly, they are focused on the software only. Sometimes, they also take into account the hardware components.
But what about the other aspects of the product? What about client support? What about operations? What about sales? What about security? The end-to-end product experience of the users is not only impacted by the working core product. It is the total package.
To be truly product-centric, companies should find a way to organize around the complete product. This means breaking the traditional silos.
I’m not talking about Agile scaling approaches like SAFe or LeSS. You may (or may not want to) use such a scaling approach to build parts of the product. But organizing around the complete product involves more. It means establishing a way of collaboration between all involved.
Some refer to it as organizing around value streams. Whatever it is named, as long as everyone involved knows how to reach out to each other and work together to reach their goals. I want to highlight unFIX as the best way I know to model your organization around( your product of) value.
Put the outcome centre stage
Churning out output regularly is not a success in itself. It only becomes a success when the output has a positive outcome. This is why any effort you put into the product should be guided by the desired outcome.
You can determine the desired outcome of their entire product experience, like “Offering our clients the best secure payment experience”. You can also determine it on pieces of the product, like “Having the best fraud detection of the entire industry”.
Once everyone knows and subscribes to the outcome you wish to achieve, you can focus on working towards this. It allows you to define and prioritize actions on your desired outcome.
Don’t put full trust in your value assumptions
The final topic many Agile teams miss is that assumed value is worthless. Don't get me wrong: it’s absolutely fine to work with assumptions when you define and prioritize your work. But they are rarely what will actually happen.
You may have information that implementing a certain feature will result in 20% user growth. It’s even logical to prioritize this over topics that have less promise. However, it is vital to check this: what is the real outcome of your updated product? It may be worse than expected. It may be better. You may have other outcomes you didn’t even consider.
Also, you should check this as much as possible. Don’t invest everything but the kitchen sink and then conclude at the end that it didn’t bring what you expected. Make small investments to find out quickly if you are moving towards your expected or desired outcomes.
You can’t put full trust in your value assumptions. However, you can use your assumptions to determine what you should do to verify them and take these learnings to optimize the chances of achieving them.