Your team releases several features, works hard, but the results don’t show up? Now understand the main causes of all this

By Filipe Machado and Thiago Fregni

In any business, whether it is a digital product or not, one of the main concerns is to meet the needs of the stakeholders and this ends up becoming one of the main goals to be achieved. With this, the team works hard, strives to launch several features, but is leaving aside a very important goal: maximizing the value and return on investment of that initiative.

In other words, even though Agility has been implemented and deliveries are happening more quickly, there are still stakeholders who are super unhappy. “There is nothing so useless as to do with great efficiency, what should not be done.” This quote by Peter Drucker is one of those that can summarize this scenario in a simple way. The team is working well, with a lot of functionality in production, but are they doing something really useful?

Does this sound common to you? Because it really happens in many businesses that are starting a digital transformation and for three main reasons:

• Value maximization and Return on Investment

Generally, the Product Owner is very concerned about serving the stakeholders and ends up leaving aside one of their main responsibilities, which is maximizing the return on investment</strong >.

• Sense of purpose

It is common for the team (Agilista, PO and Devs) not to know clearly what the objective of the product is or to have no vision as to why they are working on a certain demand. They know what it is, how it should be done, but not why – have no sense of purpose!

• Discovery/Ideation/Upstream 

Product value maximization, that is, what the customer receives at the end, needs to go through a process of discovery and refinement, before starting development. And that’s not always the case!

But what is the root cause of this problem?

It is possible to identify some signs that cause these situations described above. The main ones are:

• Low autonomy for the Product Owner, who depends on other people to make decisions and clarify details;
• Product Owner who does not have the correct competence;
• PO order taker (Proxy/Scribe PO), which does not have ownership of the product. It takes note of the requests without understanding the reason for the request and what the expected results are;
• Time is concerned with filling the capacity. That is, during Planning meetings, there is a greater concern with “fixing” enough backlog to keep everyone occupied, than actually generating value for the customer;
• PO that doesn’t know how much each PBI costs and has no idea of ​​the team’s cost, which makes it impossible to make trade-offs based on RoI;
• Teams that do not have clear goals, making it impossible for them to make choices and stay focused on what generates the most value;
• Does not have Discovery (UX). That is, as soon as the request arrives, it goes straight to the team to develop. There is no process in which the customer is involved and hypotheses are treated as truths;
• There is no Customer Centric view, focused on the consumer/user.

Well, if you’ve identified some of these points above in your transformation team, you’re making this mistake. And this can be seen in an agile team that is still in the traditional work paradigm.

Resolving these issues

When we identify this scenario – which is quite common, we do a very intense job of coaching with the Product Owner, with the Scrum Master and with the stakeholders. For this, we perform techniques such as:

– Create a discovery team: in order to find out which features should be implemented to meet the users’ needs;

– Techniques for sorting the backlog: the backlog must be sorted and these techniques help us sort them according to the goals to be achieved ;

– Create an agile treadmill very clearly using Flight Levels: this technique gives portfolio visibility until reaching the end user’s hand;

– We organize teams by Value Stream linked to the users, with clear objectives, using OKR’s, for example;

– Definition of product objective and make it clear what value (increase sales by 10%, increase conversion rate by 5%, among others) expected to be achieved by that item, plus value of items;

– Roadmap: an overview of the product’s next steps;

– Use data for decision making in backlog items;

– Hypothesis Concept Creation: a great way of working that helps to validate hypotheses is called HDD (Hypothesis Driven Development). This method helps in writing our backlog, aimed at validating hypotheses.

In general, we try to give the correct purpose to the team as a whole, linked to value for the customer or business… Because when you don’t know where you want to go, any path will do. And so work becomes efficient, but not really effective!

More value delivered, with less investment

Solving these flaws during the product development process with an agile team, it is possible to have several benefits, including:

• Be able to work in the empirical process, always focusing on the desired objective;
• It makes it easier to manage stakeholder anxiety about results;
• The stakeholder is happier with the delivery, as it is linked to the purpose, with a focus on really generating value with the initiative;
• The stakeholder’s trust with the team improves;
• In short, more value delivered, with less investment and a focus on maximizing the initiative’s value and return on investment.

We hope you can apply these suggestions in your daily life. Any questions, we are available to help… Just contact us!