As someone that frequently has work reviewed by crossfunctional groups prior to implementation, I only object to change requests that I feel will make the product significantly worse. There’s simply too much value lost in debating nitpicks.
I think that is a fine but suboptimal approach. Suppose that the team has a disagreement in a change request but agrees that it is worth an appetite of 10 minutes of discussion. In that case, it is worth having a quick discussion. The problem is when when the discussion goes (way) beyond that, but setting an appetite should hopefully prevent that problem from happening.
In practice it could be difficult to stick to such an appetite even if it’s agreed that that is the appetite, so I think the risk of not sticking to it is something that should be factored in.
I also think that the value to such objections is usually mostly about learning for the future. Ie. you may object to some implementation that has a minor immediate affect on the product, but the implementer learns from this and it prevents them from making the mistake over and over again in the future. I think this can be worthwhile even for nitpicks. Ie if a two minute exchange leads to a minor improvement in the implementers code style over the course of the next two years.
As someone that frequently has work reviewed by crossfunctional groups prior to implementation, I only object to change requests that I feel will make the product significantly worse. There’s simply too much value lost in debating nitpicks.
I think that is a fine but suboptimal approach. Suppose that the team has a disagreement in a change request but agrees that it is worth an appetite of 10 minutes of discussion. In that case, it is worth having a quick discussion. The problem is when when the discussion goes (way) beyond that, but setting an appetite should hopefully prevent that problem from happening.
In practice it could be difficult to stick to such an appetite even if it’s agreed that that is the appetite, so I think the risk of not sticking to it is something that should be factored in.
I also think that the value to such objections is usually mostly about learning for the future. Ie. you may object to some implementation that has a minor immediate affect on the product, but the implementer learns from this and it prevents them from making the mistake over and over again in the future. I think this can be worthwhile even for nitpicks. Ie if a two minute exchange leads to a minor improvement in the implementers code style over the course of the next two years.