You can use the extra capacity and flexibility that you get from Continuous Agile to increase the speed with which you release changes (increase velocity), or you can use it to reduce the number of errors, crashes, and usability problems (increase quality). The PO will often be called on to balance the need for quality with the desire for velocity.

We can show the trade between quality (Q) and velocity (V) with the following chart.

You can increase Q by reducing V and holding each feature longer for testing and improvement.

You can increase V by reducing Q and finding more problems in parallel. This is the "using the user" tactic. In a continuous process, if you force releases out with some problems, you will find and fix problems faster.

As quality increases, velocity decreases. This explains why companies try to hold products in "beta" for a long time. They can get away with lower quality, and it increases their velocity.

Quality typically improves during the life cycle of a software project. We can divide this chart into some quality bands that show stages in the lifecycle of the software.

As a product manager, you don't have much influence on this curve over the short term. It is set by your team and your process. However, you can move on the curve by setting quality standards. You can allow releases with increased quality and decreased velocity, or decreased quality and increased velocity. You can set quality standards by deciding to release to audiences with different quality requirements - alpha, beta, and full. You will get to market faster, with a higher quality product, if you know when to switch. You should not do it too late, because you will waste time to market. But, you should not do it too early because you will slow down development.

One paradox

The fastest way to increase Q is to increase V. To increase V, you decrease Q. So, you decrease Q to increase Q. Then, you find and fix problems faster, and Q increases faster.

The lesson of this paradox is that you should not try to move to quickly out of beta quality, to high quality. This will kill your velocity and delay your project. This is a classic mistake from a mature team with high quality standards or high risk aversion. To make this team feel better about releasing with lower quality, you should give them options to release to smaller "beta" type audiences.

Economists call this type of chart an "efficient frontier." You can be inside the line, with worse quality and/or velocity - just stop paying attention. But, it is unlikely that you will get outside of the line. That is why you lower velocity when you insist on increased quality.
Consider the following chart.

In the picture above we use monthly dots show two possible paths for the product. In one world, the software travels up the quality-velocity curve and gets safely out of beta quality after about three months. In the second world, we have strong quality enforcers. They make changes (like holding back releases) that reduce velocity and also reduce the speed of finding problems. They want to increase quality with the same velocity, but this is not possible. If the team is working efficiently, they can only make changes that reduce velocity. So, it takes them 5 months to get to the same place.

How to increase quality AND velocity

The long-term solution is to improve your process so that it has higher quality at every velocity. You cannot do this by adding QA people. QA people will find problems, rather than eliminate them. You can do it by improving other layers of your development process:

• Frequent full releases to flush out problems
• Monitoring and measurement and feedback directly to developers
• Automated testing, and more layers of automated testing
• Engaged story owners