Engineers with an open source coding mentality: Tasks are discussed on pull requests once they’re finished, but not in advance during grooming or sprint planning sessions. (They tend to operate in a distributed team mentality.)
Agile Failure Patterns in Organizations 2.0
Stefan Wolpers
1.4K2

I sense that you encountered some missuse of pull requests in your career.

Discussing stories and tasks is of course not the job of pull requests but of the planning. And of course it’s important to clarify the customer value behind a story and to come up with an agreed rough plan how to tackle the technical implementation upfront.

As long as everyone agrees to that, pull requests and an open source mentality are a great way to ensure a high code quality and are a sign for a sophisticated code review. Especially when central components are shared between product teams, pull requests are perfectly suited to balance between dedicated responsibility for code quality and weak dependencies between teams. This works perfectly fine as long as pull requests are handled with highest priority (to not block others) and potential reviewers from other teams are invited to plannings so that they can contribute to the implementation plan.

In such an environment pull requests provide a standardized and proven method to deduct structured code reviews and are by no means a contradiction to agile principles.