The Product Owner doesn’t allow us to work on technical tasks and remove the Technical Debt!
– The Developers
Agile teams often encounter the following situation:
The Developers accumulate Technical Debt and want to work on it but the Product Owner is worried about deadlines and focused on delivering for demanding stakeholders.
The conflict is inevitable!
Engineers argue that the code needs certain improvements and those must be addressed immediately. However, the Product Owner insists on delivering new features and meeting deadlines. There are escalations on an emotional level. People get frustrated and work relationships are endangered.
Does it sound familiar?
What should we do?
First, we need to make sure everyone understands the problem before discussing possible solutions.
Start with “why”, remember?
Product Owners are under pressure. They deal with inpatient stakeholders whose needs grow exponentially. There are regulations, take GDPR for example, that you need to comply with and simply can’t postpone. Market opportunities that the business can’t afford to miss… And out of nowhere the development team states,
We need to change the framework ASAP. It is critical!” or “We have to refactor the software architecture, otherwise we’ll be stuck!”
Bummer!
Roles and Goals
Remember, we’re all one team and we have a common Goal – make our customers happy!
We do that by delivering frequently a high-value product at the best possible quality. Both aspects are key to our success and should be taken into consideration at all times.
In general, the Product Owner is responsible for maximizing the value delivery and priorities, while the Development Team owns the software and is responsible for its quality.
Inevitably, the nature of software development is to generate Technical Debt and by definition, it is owned by the Development Team. A common misconception is that the Product Owner gets to decide when and if the team will work on it. Every decision regarding the code quality is done by collaboration between the two roles and trade-offs should be made on both sides.
Product Owner gets Technical
The collaboration gets harder, as the Product Owner may have little or no knowledge about technical implementation details. Thus, she may have difficulties understanding the importance of prioritizing tasks that cost a lot of time and realizing the implications that might arise if not addressing them. She might also not understand how these are more valuable than a piece of new functionality.
If that’s the case, the Development Team must educate the Product Owner. She needs to have at least a high-level understanding of the product implementation, what’s the architecture, how the various software modules work together, and what are the limitations and possibilities. It’s also useful for her to learn which essential functionalities the tech improvements will enable.
Imagine you’re driving a car, and suddenly the check engine light turns on. You may not understand how the engine works, but it is necessary to understand there’s a thing called “engine” and if it has a problem, bad things may happen, so immediate actions should be taken!
It’s the same if you’re a Product Owner – you may not understand software development, but you need to know when your product is about to crash and take action.
But what if it’s the “washer fluid light” turned on? Yes, you should fix it eventually, but you still could go forward and ignore it, accepting the inconvenience of not being able to clean the windshield.
By all means, the car requires regular maintenance to expand its life and fulfill its purpose. It is the same with your product.
Developers drive the Business
Having a common understanding of the system will help the whole team make better decisions and trade-offs. However, the developers also have to understand “the why” of the business needs and goals. It’s not enough just someone to tell them there’s a deadline they have to meet. When engineers are engaged, and you give them a certain level of responsibility for the product’s success, they would suggest when and how to address the Technical Debt.
It’s all about us, all about TRUST
It all leads to the question of trust.
Ask yourself:
Does the Product Owner trust the developers are making the right technical choices?
Does the Development Team trust the Product Owner the goals aren’t set arbitrarily?
If the answer to any of these questions is “No”, there is an underlying problem you need to focus on first.
Know the Enemy
What exactly is Technical Debt? It may be bugs, bad software implementation, improving software security, the SDKs become obsolete or new technology. Being able to distinguish what kind of issues you’re dealing with, is key and you can’t afford to ignore it! Technical Debt grows like cancer for your product, and the Dev Team is the only one who can provide the cure.
Backlog Upgrade
You can tackle Technical Debt in many ways. One possibility is for developers to describe the needed work in a dedicated type of Product Backlog Items, like a Technical Story or a Task. Add the tickets in the Product Backlog and prioritize them along with other items. The Product Owner and the Dev Team do the prioritization together as anything else. Some teams decide to have a certain amount of Sprint’s capacity dedicated to Technical Debt for every Sprint.
Also, the developers raise technical issues, but it doesn’t mean they can not describe them in business value items, like User Stories.
Let’s give the following example:
Due to bad software design, the login functionality takes a long time for the end-users to enter the system. This could be put as a User Story like that:
As a user, I want to be able to login into the application faster, so that I’m more satisfied with the user experience.
Be careful though, a common mistake many teams do is to write “fake” User Stories, like the following:
As a developer, I want to change the framework, so that the software is better.
This definition doesn’t necessarily reflect what’s the end user’s benefit, which should be the goal for a User Story… to be called User Story.
As a rule of thumb, always try to describe the technical work in terms of business value. It will make the conversations and decisions easier and also it won’t look like the product is not progressing in terms of value.
Loaded User Stories
The developers are expected to constantly refine and improve software quality as part of the day-to-day work. A good practice is to update the existing Definition of Done agreement and outline explicit policies to deal with the Technical Debt as an integral part of the software implementation.
In some cases, you can “embed” specific Technical Debt tasks in the User Stories. That means the development team plans to do “extra work” around the implementation of the new features that address software improvements. Usually, the team describes this work in the form of sub-tasks. Of course, you should consider those when making estimations.
Treat the Disease
You may come up with other ways to deal with the Technical Debt.
However, it is important to understand why you generated it in the first place and take action to prevent it from emerging.
The following questions might be useful to understand the root cause:
- Is the team technically competent enough?
- Is the team under pressure, thus making shortcuts and sacrifices quality?
- Is the team motivated and engaged with product success?
- Is the team empowered to make technical decisions?
- Is high quality considered a must?
Sacrifice the Pawn
In rare situations, Technical Debt is acceptable for short-term tactical decisions. If it’s a necessary approach, make it explicit and plan to improve on it sooner than later. Be careful, though, it doesn’t become a tendency, as such shortcuts build on top of each other and become the reason for troubles. Cleaning and refining the code should be part of the daily routine for every developer.
Agile software development is all about frequently delivering value to customers while maintaining the highest technical quality possible. The two goals always go hand in hand, like two sides of the same coin, and how you achieve them depends on your context. There is no silver bullet to tackle all problems, and the best possible solutions will emerge from the collaboration between business and technical people. Trust is the foundation of any decision.
