Feedback lifecycles: How to reduce them in your developments. Why wait until the pull request to receive feedback?

Pair programming is one of the best tools that we have as a team when we want to speed up a feature and share the knowledge between the teammates. And it helps to reduce the feedback lifecycles.

In my opinion, the main advantage that the pair programming gives is that you reduce the feedback life cycle. How does it do?:

  • The answer is pretty easy, at the moment that you are doing pair programming, you are giving and receiving feedback because when you are doing pairing one of the devs are writing code and the other is helping him and providing feedback and vice-versa.

So, why do we have to wait until the pull request to have the proper feedback? Why do we have until the code review to share the knowledge?

If we use a traditional way of developing, where one developer writes all the code without sharing the information and receiving feedback. You are missing the opportunity in most of the cases of providing the best quality and a consensus solution. And maybe you can find some surprises in the latest phases of the flow.

In the beginning, Pair programming is a little bit difficult to use because the learning curve is hard and in most of the cases we aren’t used to working together during a workday or so. Also, Pair programming has some social and cultural connotation.

In my experience, using pair programming in my team we are improving the customer lead time and the local lead time in a 30%, furthermore, we use pairing not only the development phase but also in the refinement even in QA flows if it was necessary. Therefore in the team which I work, there aren’t silos and all the team members are more or less aware of the different features that we are developing.

Pair programming is one of the best tools that we have as a team when we want to speed up a feature and share the knowledge between the teammates. And it helps to reduce the feedback lifecycles.

In my opinion, the main advantage that the pair programming gives is that you reduce the feedback life cycle. How does it do?:

  • The answer is pretty easy, at the moment that you are doing pair programming, you are giving and receiving feedback because when you are doing pairing one of the devs are writing code and the other is helping him and providing feedback and vice-versa.

Therefore, why do we have to wait until the pull request to have the proper feedback? Why do we have until the code review to share the knowledge?

If we use a traditional way of developing, where one developer writes all the code without sharing the information and receiving feedback. You are missing the opportunity in most of the cases of providing the best quality and a consensus solution. And maybe you can find some surprises in the latest phases of the flow.

In the beginning, Pair programming is a little bit difficult to use because the learning curve is hard and in most of the cases we aren’t used to working together during a workday or so. Also, Pair programming has some social and cultural connotation.

In my experience, using pair programming in my team we are improving the customer lead time and the local lead time in 30%. Furthermore, we use pairing not only the development phase but also in the refinement even in QA flows if it was necessary. Therefore in the team which I work, there aren’t silos and all the team members are more or less aware of the different features that we are developing.

Don’t forget, that you can’t force the people to do pairing, it is something that the team has to choose. All the members have to be comfortable with this. Otherwise, the pair programming won’t help the team to speed up the projects and at the end, it will be a problem.

Eventually, before finishing this article. I would like sharing with all of you one of the best articles that I have read about pairing. It was written by Martin Fowler:

Originally published at AwakeDeveloper.