Being a Product Owner on a large Agile project is hard. Not only are you trying to get a consensus from numerous business stakeholders, all with their own opinions and agendas, you are having Scrum masters asking for your undivided attention for release and sprint planning. Not only do you have to juggle the priority of all the business features that need delivering for particular business milestones you are expected to understand the relative priority of technical improvements, tech debt and bugs. Most Product Owners understand the business better than the technology so when they are asked to determine the priority of “Refactoring a data layer to deal to the transient failure of a cloud database connection” vs “building a support tool to replay failed messages” you can’t blame them if they struggle.
In many organisations, despite moves towards agile ways of working there are still delivery pressures and there are still expectations that a fixed scope will be delivered in a fixed time. So when an agile project has such a focus on milestones and there are feelings outside the project that those milestones are not being met there is an understandable motivation for the PO to move the product forwards. The PO starts to think only in terms of features and all the other quality criteria such as does the feature perform, is it secure, can it be modified easily in the future, can it be supported, become hindrances. Inexperience POs forget they need to represent the concerns of the whole business and not just the users of the product.
I have worked on projects where there was tension between the Architecture and Product Owners. The Product Owner supported by the Scrum master wanted to focus purely on business value in terms of features delivered to hit a business milestone. Emerging design was promoted over any type of non-functional planning. This resulted in a number of stories being created to fix security, operational, and performance problems after the fact. And these types of stories were viewed with suspicion by the Scrum Master and the PO, leading them to drop down the backlog.
Over time this friction and tension caused collateral damage. It became difficult to justify
- Resolving technical debt
- Implementing good integration patterns
- Fixing technical bugs
- Generally doing anything that reduced technical risk
- Building tools to help detect data integrity problems
This work was always challenged because it was seen as though it wasn’t the highest business value. “Of course delivering feature X is more important than spending time building a tool to identify and fix data corruption”. The projects preoccupation with milestones meant the they could not see beyond delivering new features. This work was seen as just something, “the architects’ wanted” or “the development team were moaning about”.
Business value means more than new features.
Is Business Value really the rate at which you can deliver new features?
If technical debt mounts up it generally becomes harder and harder to add new code to the solution and maintain existing code. Delivering new feature slows down.
Those architectural waivers for non-compliance will expire at some time . Soon you will be forced to resolve them as you’ll not be able to release anything else until you do. Now the project cannot release any new features until those problem are resolved.
A bad integration implementation means that integrating with additional systems becomes more difficult. The effort to maintain existing integration can grow exponentially. Again over time building new features gets harder.
The list of bugs is going nowhere when focusing on new features. Perhaps your extensive bugs are causing you to lose customers and soon there will be no one left to use your new features.
Addressing all of these things in a timely manner means you can continue to deliver new features at a consistent rate. Not addressing them slows down the rate in which the project can deliver new things. Therefore when assessing the business values of these types of technical stories perhaps you are looking at the wrong thing. Maybe you should look at their potential to reduce the rate at which new business value can be delivered if they are not done.