The Scrum guide describes a Product Owner as a value maximizer who maximizes the value of the development team’s work. It recommends prioritizing the product backlog as the primary way of achieving the maximized value by ensuring that the highest valued items are at the top.
However, any effort to maximize the value of the team’s output is limited without addressing the following two areas:
· Time to Market
· Ability to Innovate
Ignoring these two factors can really limit the actual value created by the development teams.
Time to Market (TTM)
TTM is the total length of time it takes right from the moment a product or a feature is conceived until it becomes available for the customer’s use. For development teams, this can be translated to the time between when the team starts working on a feature and when the feature is delivered for release.
Why is it important: A shorter TTM gives you a competitive advantage, where you can react faster to market or strategy changes.
It doesn’t matter how prioritized your backlog is or if the teams are working on the highest priority items if the work cannot be released on time. A McKinsey study reports that, on average, a product that ships six months late, earns 33% less profit, while a product released on time with 50% overspend on development in comparison suffers a loss of 3-5% in profit.
Agile helps you to shorten the TTM by implicitly applying the 80/20 rule, where the product owner prioritizes the features to be implemented based on their value (ROI) to the product. However, teams still need to watch out for the following factors that can increase their Time To Market:
· Non value-added activities in the product development and delivery process, such as lengthy code review processes and long approval cycles.
· Too much dependency between teams contributing to increased lead time.
· Lack of automated testing and CI/CD.
Ability to Innovate:
Ability to Innovate is the organization’s capability to work on new features or functionalities that might better meet a customer’s needs. It is necessary but often a luxury for most organizations. Most software is overloaded by non-valuable features.
Why is it important: As low-value features accumulate, more of the organization’s budget and time is consumed maintaining the product, therefore reducing its available capacity to innovate.
Ability to innovate = Total time teams spent on working on new features/Total time teams spent on fixing bugs or technical debt
Some factors that might signal a low Ability to Innovate are:
· Low Forecast accuracy
· High Velocity fluctuations
The main things that can limit a development team’s ability to innovate are:
1. Buggy Product: A product with a high number of bugs might signal low product quality, which can keep teams engrossed in fighting bugs and away from working on new stuff. Agile strives to prevent bugs rather than fixing them. Therefore, the inspection and adaptation based on the empirical evidence gathered through root cause analysis on the bugs should highlight any underlying factor for a buggy product. These reasons can range from a vague Definition of Done, ambiguous requirements, bad coding practices or a lack of quality assurance.
2. Maintaining or Supporting multiple versions: Supporting multiple versions of the product increases the maintenance activity that’s required across various versions of the product. Therefore, if a team’s major chunk of bandwidth is spent on maintenance or support requests, it might be worthwhile looking into how many versions of the product you are supporting and is there a way to reduce this.
3. Ease of Upgrade or Moving to new versions: Before you look at limiting your supported versions, it is beneficial to understand the reason why customers aren’t upgrading to the latest innovation released by the team. How easy or hard is it for your customers to upgrade or move to the next released version? This is a very important question as it directly influences how many of your customers move to the latest released version. This in turn helps to get your customers on to a more limited number of versions by ensuring that they have no issues with upgrading to the latest released version.
4. Technical Debt: Every team or organization wants to deliver new features. But with every feature you add, you’re also adding a complexity cost. Over time as the product matures, new functionality runs an additional risk. It might further dilute your value proposition and suck resources away from the core elements of your product. Even though technical debt hinders your ability to innovate, it’s impossible to avoid for most organizations due to the way it adds up gradually over the product lifetime. However, understanding customer needs instead of simply addressing customer needs, using good coding practices and a defined debt management policy are a few strategies that might help you to keep it in check.
5. Centralized decision making: Centralized decision making limits the decisions to a single team or person, which can lead to a loss of 80% of the innovation that an organization is capable of. In day-to-day work, various decisions are required. Centralizing these decisions to a single person or team creates a bottleneck and increases the risk of a single point of failure. Therefore, decentralized decision making is preferable when it can be achieved through self-management or organizing teams.
It’s important for teams and organizations to evaluate their Time to Market & Ability to Innovate to ensure that the work being done in teams is actually delivering valuable outcomes for customers that lead to improved customer experiences.
Therefore, organizations or teams need to continually evaluate their Time To Market and Ability to Innovate by asking the following questions:
· How fast can the organization learn from new experiments and information?
· How fast can you adapt based on the information?
· How fast can you test new ideas with the customers?
· What prevents the organization from delivering new value?
· What prevents customers or users from benefiting from that innovation?
- Schwaber, Ken & Sutherland, Jeff. 2020. The Scrum Guide. ScrumGuides.org
- “Agile Metrics with Evidence Based Management (EBM)”. Scrum.org 2021 https://www.scrum.org/resources/evidence-based-management
Should you need assistance to deliver business value by limiting your time to market and enhancing your ability to innovate, check out the Agile solutions we have for you. Ammeon’s Agile experts are at hand to talk to you.
Product Owner | Ammeon