Let’s talk a bit about: quality vs quantity? I’ll anchor this debate in Scrum – so the main actors will be Product Owner and Development Team – however the same would apply to any other Agile framework.
Imagine there are only two dimensions – technical excellence on one side and output (number of features delivered in one iteration) on the other.
Where the Dev Team would like to be, and where the Product Owner? Answering the question, the Dev Team is considered mostly as quality defenders, while Product Owner is the output pusher.
Have you ever thought of where the Customer would like to position themselves?
If your answer is no, just step back and try to put on their shoes. He is the most important of all three. In a healthy team situation should look more or less like this:
The difference between Dev Team’s and Product Owner’s priorities creates constant tension between them, stimulates discussion and encourages knowledge sharing. This difference actually is a very good thing. There should be such tension (I prefer using ‘tension’ rather than ‘conflict’, as some would say) between the Dev Team and the Product Owner. Why so? Questions raised by the Product Owner, even if not always comfortable, help the Dev Team to stick closer to the business value. On the other side, questions from the Dev Team make the Product Owner to get closer to technical detail and in result enforce the quality.
Coming back to our main topic – where the Customer would like to be? The answer is simple: in between the two.
Customer don’t need so many features as Product Owner would like to deliver, and also don’t need that high technical quality as the Dev Team would like to develop. The right place for the Customer to be is then right in the middle:
This desired balance well supports delivering a product that fulfills users’ needs, providing proper (but not crystal clear!) quality for a reasonable amount of money spent.
Let’s now think of what are possible deviations from the perfect state and their consequences.
Huge distance between Product Owner and the Dev Team
The bigger distance is, the stronger is the tension between Product Owner and the Dev Team. In this case conflict may arise, which will force both sides to just stand on their positions and defend technical excellence or output maximization, destroying proper cooperation inside the Team at the same time. Some of possible symptoms to identify this unhealthy situation are:
- refinements often end with argument on ‘do it fast’ against ‘do it right’;
- lack of understanding: Product Owner does not accept high estimations, while the Dev Team doesn’t want to manage technical debt, only decrease it to 0;
- technical debt being managed solely by Dev Team;
- prioritization of Product Backlog made by Product Owner without consulting the Dev Team.
If you are part of such team, you should try to decrease distance and focus on mutual understanding.
Technical debt should be made visible to show Product Owner the impact of focusing only on output maximization. On the other side business value should be always visible and explained to the Dev Team, making Product Backlog priorities clear for them. You can also read how to manage technical debt.
Product Owner and Dev Team in one place
The closer the Dev Team and Product Owner are, the less tension is between them. Having the same perspective on both sides unfortunately may lead to stagnation. Neither quality nor quantity will have advocates ready to fight for them. This situation is similar to a team in Norming phase (according to Tuckman’s stages of group development) – team may sacrifice progress and learning opportunities, just to avoid tensions. Possible symptoms are:
- Product Owner always agrees on any refactor or tech debt iniciative proposed by Dev Team (in this case both parties are probably much closer to quality side);
- Dev Team always delivers functionalities requested by the Product Owner and tries to do this as cheap as possible (quantity side prevails here);
Increase of distance in such team will help you to benefit from PO-Dev Team cooperation and also allow both sides to develop, learn and become more aware of the product.
Stagnation is a huge risk for long-life teams, and you should try to avoid it. Product Owner should always think from the business value perspective, while the Dev Team from the quality perspective – setting such roles during refinements and other meetings should allow to extend distance a bit.
Customer outside the boundaries defined by Product Owner and Dev Team
If the Team pushes to much for quality, Product Owner may move too close to the Dev Team and Customer will be outside. In this situation Customer won’t be happy. Product development (from Customer perspective) will be to slow and possibly your competitors can benefit from it. Providing quality is very important, but response time for new or changing needs of the Customers is something which keeps products alive.
Too much pressure on quantity may end up with Customer stop using your product due to its low quality and multiple errors. Introducing too many features which are not tested properly will decrease quality even further. At the end the Customer will probably use less than 50% of features from your product – so you need to make sure that this 50% will be working fluently without any drawbacks. Increase in technical debt will also lead to growing maintenance costs and further development slow down.
In those cases the Dev Team is not working close enough to the Customers to be able to understand their needs. What is your plan to satisfy your Customers if you don’t know what are their expectations?
It is also much harder to find out what are underlying causes of those two anomalies. Whether you want it or not, the Customer is always a bit further from product development than the Dev Team or Product Owner. One of the most important symptoms here can be an unhappy Customer.
To conclude – discussion quality vs quantity is very important, and it should be endless.
Inside your team you should have always two advocates – one for quantity (possibly Product Owner) and one for quality (possibly Dev Team).
All the fun lays in assuring small and conscious movements between Product Owner and Dev Team, but keeping in mind two things:
- Customer should always be between Product Owner and Dev Team.
- Distance between Product Owner and Dev Team should create creative tension.
And how do things work in your team?