In the previous couple of blog posts I have gone through a couple of sections of the Scrum Guide. But there are other things to know outside of the guide that will be helpful in being an effective Product Owner.
Evidence-based Management
Evidence-based Management is how to continuously improve business results by measuring business value and using empirical (evidence-based) management. It can be defined as:
...an empirical (evidence-based) approach that provides organisations with the ability to measure the value they deliver to customers and the means by which they deliver that value, and to use those measures to guide improvements in both.
Or, in other words, continuing to improve through measuring and using evidence. Evidence-based Management provides the ability to measure the value delivered, how that value is delivered, and then guides improvement by using those measures.
The reason for focusing on Evidence-based Management is so that you don't fall into the trap of adopting Agile principles and the framework, and thinking that you're automatically adding value to the products that you created, as well as the business that you created it for, when it's not necessarily the case. It's very easy to get lost in improving processes and activities rather than improving the value of the products that you created. Focus on the why, not the how.
Evidence-based Management consists of four Key Value Areas (KVA):
- Current Value
- Time to Marked
- Ability to Innovate
- Unrealised Value
Each of these key value areas either concern the ability to add value or the ability to deliver value.
Current Value and Unrealised Value are about adding value. The Ability to Innovate and Time to Market are about the ability to deliver value.
Current Value
Measuring Current Value is about maximising the value that the organisation can deliver to the customers and stakeholders at the present time. Ways to measure this might include:
- How happy are the users and customers today?
- Is their happiness improving or declining?
- How happy are your employees?
- Is their happiness improving or declining?
- How happy are your investors and other stakeholders?
- Is their happiness improving or declining?
It's quite obvious why you might want to measure how happy customers are and also investors and stakeholders. But it's also important to measure how happy your employees are, because the employees are the ultimate producers of value. Engaged and motivated employees know how to maintain, sustain and enhance, and are one of the significant assets of an organisation. Simply put, happy employees are more productive.
Unrealised Value
The goal of looking at Unrealised Value is for the organisation to maximise the value that it realises from the product over time. To measure this, you might want to frequently ask questions such as:
- Can any additional value be created for our organisation in this market or other markets?
- Is it worth the effort and risk to pursue these untapped opportunities?
- Should further investment be made to capture additional unrealised value?
This roles in nicely with Product Discovery as these questions can outline the potential for new product ideas.
Time to Market
The Time to Market is about looking at the amount of time it takes for the organisation to deliver value. You can measure this by asking questions such as:
- How fast has the organisation learned from new experiments?
- How fast can you learn from the information and adapt?
- How fast can you deliver new value to the customers?
To improve Time to Market, you can improve things like:
- Reduce bottlenecks, such as communication bottlenecks or process bottlenecks.
- Finding out where those bottlenecks exist and trying to eliminate them or reduce them.
- Improve the delivery pipeline with automation and better processes.
- Reducing and keeping a handle on technical debt
- Keeping meetings efficient and down to a minimum.
- Making sure that your Spirits are actually delivering Increments at the end.
Ability to Innovate
Your Ability to Innovate is about looking at the organisation's ability to deliver new capabilities and innovative solutions. you could measure this by asking questions such as:
- What prevents the organisation from delivering new value?
- What prevents customers or users from benefiting from that innovation?
Things that hinder your ability to innovate are similar to the things that hinder your time to market, such as:
- Having too much technical debt
- Having a complex and/or inflexible application architecture
- Being stuck on legacy systems
- Not utilising cloud infrastructure
- Poor code management
- Lack of stability in production
- Not having a development environment that mirrors the production environment
- The organisation is not able to ensure the Developers have access to the latest and greatest tools and software.
- Poor employee retention / employees are unmotivated
Ensure continuous improvement by reviewing the Key Value Measures and making incremental improvements to the questions in the process. Act on all feedback to your Key Value Areas.
Scrum Theory: Empiricism
Scrum is founded on empirical process control theory; or, in other words, knowledge obtained from working in an experience-based and evidence-based manner to make decisions and improve.
Scrum is an iterative, incremental approach to optimising predictability and control risk. You're working iteratively, basing your decisions on the work that's been done and the knowledge that's been gained. Then you are reviewing that experience to make decisions based on the actual reality of what's being experienced. You're also releasing iterations of the product, and you're basing your decisions on the evidence that you've seen from the work that's been done.
There are three pillars which uphold every implementation of the empirical process. These are:
- Transparency - all members trust each other; they share knowledge; avoid blame culture; everybody is onboard with the same vision; the Sprint Goal is clear.
- Inspection - work is reviewed when completed; inspection of the Sprint Increment and Product Vision in Sprint Reviews; inspection of the Sprint in Sprint Retrospectives.
- Adaptation - based on the results of the inspections; responding to change.
Feature Teams vs Component Teams
A Feature Team is cross-functional. The Developers work in a cross-functional manner and are an example of a team that takes a feature of the product (i.e. something that they need to build for the customer) and they develop it.
The Component Team focuses on one particular component of the product. This is quite common when using the Waterfall methodology.
For example, if you're building a product that requires a three tier architecture, such as a presentation layer, an application layer and a database layer, you might have a dedicated team for each of those three components.
Those teams specialise in their respective areas. But in order to build a product, there's going to be a dependency between all of the different components and all the different teams. By using a Component Team structure, you are creating more dependencies than you would be if you were using one single feature team.
One of the advantages of using a Component Team is, of course, specialisation, but also the ability for that component team to serve more than just one team or one product inside of the organisation to centralise products and services.
But the disadvantage is that the team that is creating the Increment needs to go outside of their team in order to produce that Increment and to produce that product. That, of course, creates a dependency on that particular Component Team.
As a Product Owner, you need to spot the dependency and then add that dependency to the Increment in the Product Backlog. You are able to link issues and show dependencies between Increments in planning software such as Jira.
Any Increments that have blockers should stay in the Product Backlog until the blockers have been developed/fixed.
