As a non-programmer who has sometimes joined standups as a product owner this seems like the developers are not standing up for their viewpoints in the process. The team’s I have worked on, we have an agreement that some percentage of the time should be devoted to refactoring and similar technical tasks. there may be a specific designation or it may be just a rough approximation but we respect each other enough to have a conversation about it and come to an agreement.
My role is to ensure that the overall project and deliverable is on track. I will ask questions to clarify statements made in standup. I expect questions coming to me about requirements, intent, and timing. If there are problems with external teams, I will do my best to work out that blocker. I don’t dictate how the devs do their work as long as they are able to deliver the features that were agreed on. If that is not going to happen, we can have a discussion about why and what adjustment needs to be made.
If more refactoring needs to be done, we can have that conversation. Talk to me about the cost and benefits of the refactoring and the impact on deliverables. It may be worthwhile accepting a delay in deliverables now. It may also be that those particular deliverables are important enough that the refactoring may need to be deferred even if the ultimate cost is higher. Those kinds of trade-offs cannot be done only by one part of the team but need to be weighed by the whole team.
This kind of open and respectful discussion is part of a well functioning team. If you are not getting that then raise this as a problem in retrospectives because it needs to be addressed.
My role is to ensure that the overall project and deliverable is on track. I will ask questions to clarify statements made in standup. I expect questions coming to me about requirements, intent, and timing. If there are problems with external teams, I will do my best to work out that blocker. I don’t dictate how the devs do their work as long as they are able to deliver the features that were agreed on. If that is not going to happen, we can have a discussion about why and what adjustment needs to be made.
If more refactoring needs to be done, we can have that conversation. Talk to me about the cost and benefits of the refactoring and the impact on deliverables. It may be worthwhile accepting a delay in deliverables now. It may also be that those particular deliverables are important enough that the refactoring may need to be deferred even if the ultimate cost is higher. Those kinds of trade-offs cannot be done only by one part of the team but need to be weighed by the whole team.
This kind of open and respectful discussion is part of a well functioning team. If you are not getting that then raise this as a problem in retrospectives because it needs to be addressed.