Why many Scrum Teams fail to maximize the business value
The 5 mistakes that block Scrum Teams from delivering high business value
The 5 mistakes that block Scrum Teams from delivering high business value
Many Scrum Teams fail to maximize business value. On my journey, I experienced many scenarios where teams suffer from pitfalls. Therefore, the teams fail to benefit from the advantages of Scrum, but why? Some common anti-patterns bring a significant drawback to the teams. Thus, maximizing the business value becomes a wish out of reality. The common problems I’ve seen are:
Misunderstanding of Scrum: some teams forget Scrum is a means to an end, where the goal is to maximize the business value.
Misunderstanding of value: until everyone doesn’t have a common understanding of what business value means, there will be confusion, which will prevent the teams from maximizing the business value.
No Focus: increasing the business value requires saying NO to everything that is not the priority.
Not removing low-feature value: all products have low-value features or even no-value ones, yet, such features remain available instead of being removed.
The Team is not inspecting & adapting the work dynamics: the Scrum Team should become a better version of itself Sprint by Sprint. If the Team is not inspecting & adapting, the Team may become a worse version of itself Sprint by Sprint.
Misunderstanding of Scrum
I have noticed many teams fail to understand Scrum. Many organizations believe Scrum is a process where once the roles, events, and artifacts are in perfect use, then Scrum is implemented. This perception is a vast misunderstanding; Scrum is a lightweight framework simple to understand, but complex to master.
Scrum is a means to an end, not the end itself; the whole story of adopting scrum practices is to improve business value. Once the companies and teams misunderstand this, problems will arise that will mislead teams. One classic problem I noticed is focusing on the output instead of the outcome, for example, the number of story points delivered is the most critical part. Therefore, the business value is forgotten.
I love going back to the Scrum Guide to understand better what Scrum Framework is.
A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
Scrum is:
Lightweight
Simple to understand
Difficult to master
Scrum is a process framework that has been used to manage work on complex products since the early 1990s. Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.
Misunderstanding of value
The word value can have many different meanings. Therefore misunderstandings happen quite often. I understand value varies from business to business, as well as the product nature. For example, in a marketplace, the value is different than in a bank. Therefore, the Product Owners need to understand what business value means within the business scenario they’re in. Some examples are:
Web: monthly new users, monthly recurring users, session time, bounce rate, monthly sessions, and so on.
App: daily downloads, daily uninstall, session time, monthly new users, and so on.
E-commerce: NPS score, conversion funnel, revenue, gross sales, net sales, return-rate, no-ship rate, commission-rate, and so on.
The Product Owner should understand what is relevant to the business. Therefore, discuss openly with the Development Team about how can we improve determined KPIs. Once the initiatives are clear, it is possible to evolve the product to maximize the business value. But be careful! The Product Owner should monitor the right KPIs to understand if we are maximizing the business value as expected.
I’ve seen many Product Owners and Scrum Masters obsessed with monitoring the direct use of the practices, that does not provide the best evidence of their effectiveness. For example, tracking the number of story points delivered has nothing to do with the business value. Only once the right KPI is compared within its previous results, it’s possible to evaluate if we maximize the business value.
Scrum aims to maximize value as fast as possible. That’s why we should strive to deliver small increments focused on improving a specific part of the product, then measure the results and evaluate how the business value evolved.
Scrum acknowledges that in complex environments you can’t know what will happen within a few months from now. Scrum even acknowledges that changes can happen on a daily basis, impacting the team’s progress.
Scrum embraces change.
This is why Scrum is about delivering small increments that should bring the highest value, reflect on this and then discuss and decide what would then bring the highest value.
No focus
No clear focus is a frequent problem I’ve seen. Executives tend to face a hard time defining what is the company’s priority, resulting in no clear direction. Thus, teams cannot focus; they don’t know which direction to take, because everything is a priority. The decision-makers should understand something; the decision to invest in one product means not investing in others.
“When you have too many top priorities, you effectively have no top priorities.” — Stephen Covey
As a Product Owner, I strive to understand which is the most critical KPI to improve. Thus, I can identify opportunities with the team to maximize the business value on it. A pitfall I must avoid is defining multiple KPIs to improve at the same time. If we do that, we can be sure the team will not have a chance to collaborate.
In one of the companies I worked, after analyzing the conversion funnel, we understood that the most significant drop happened between the Product Detail Page and the Cart. Therefore, we decided to invest time in improving this part. However, we chose not to look into the other drops; for example, from Cart to check-out, it was also a relevant drop, but we just ignore it for that moment.
Not removing low-feature value
A common pitfall many Product Owners fall into is saying to many times, yes. Being a yes Person leads to build an excessive amount of pointless features. Product Owners should be careful not to become an order taker, where pleasing the stakeholders become a higher priority than maximizing the value for the business. This scenario is a misunderstood instance of a Product Owner. It is known as the Clerk by Robbin Schuurman.
The Clerk is your personal waiter for all your user story serving. Gathering all the wishes, user stories and demands is what The Clerk does. (S)he isn’t focussed on achieving the product vision, nor on crafting clear goals and objectives and the Clerk most certainly never says ‘no’ to stakeholders. There’s nothing wrong with servant leading your customers and stakeholders as a Product Owner, but if your main purpose during the day is getting new ‘orders’ from stakeholders… then you’re missing the point of being a great Product Owner.
All products have low-value features; over time, we may build something useless. We should remove such features, since they bring nothing to business, besides burden. As low-value features accumulate, we need more budget and time to maintain the product or overcoming future problems, therefore, reducing the capacity to maximize the business value.
All features cost money. But only some features make more money than they cost. Each feature in your product should be able to carry its weight. It should deliver more value to users and the business than it costs.
— Maarten Dalmijn, How to stop features from killing your product
The Team is not inspecting and adapting the work dynamics
One of the beauties of Scrum is becoming a better Team Sprint by Sprint. By inspecting and adapting, the teams evolve naturally. Yet, many teams miss the opportunity and tend to remain the same version or become even worse team overtime. Why does that happen?
Some teams are not mature enough to have open discussions about problems, which holds the team from identifying the root cause and solve it. Unfortunately, some team members either avoid conflicts or tend to go to personal attacks. I believe a great Scrum Master can help with conflict resolution by mediating the discussion.
“When there is trust, conflict becomes nothing but the pursuit of truth, an attempt to find the best possible answer.”
― Patrick Lencioni, The Advantage: Why Organizational Health Trumps Everything Else In Business
I’ve come across some traditional problems within Scrum Teams that held us from evolving as a team:
Excessive Status Report: I’ve seen some Product Owners reporting daily the progress of the team, causing a communication bottleneck beyond going against Scrum. Although the stakeholders will get the status updated during the review, if they want to know the progress of the team, they can attend the Daily Scrum and listen to the Development Team.
Poor test environment: many teams are struggling with a proper test environment. However, besides complaining, the team took no action to change the scenario.
Code Complexity: most of the team members struggled with the code complexity. Although everyone was aware of the problem, no change happened to improve due to fear of conflicts.
“When you complain, you make yourself a victim. Leave the situation, change the situation, or accept it. All else is madness.” Eckhart Tolle
Wrap-Up
Scrum Framework is powerful and can maximize the value of the business. I’ve experienced that many times, however, if we want to do reach the state of the art we should:
Teams and organizations need first to understand how Scrum works, then implement it in a way that will help the business maximize its value.
The meaning of business value and user value must be crystal clear among everyone; otherwise, we might maximize something else instead.
Define clearly the priority and focus on it!
Create a process to evaluate the value of the features, then remove the low-value features, so that you don’t waste time with them.
Ensure the team is inspecting and adapting every Sprint to become a better version of itself.
Do you want to write for Serious Scrum or seriously discuss Scrum?