I would like to introduce code reviews in our agile process, my developers however think that it is a waste of time since they do not code in the same languages (front and back end dev). What is the best way to introduce it?

  • Are you the process facilitator or one of the developers who wants code-reviews? – Niels van Reijmersdal Sep 21 '17 at 7:24
  • Scrum master aka process facilltator – bobo2000 Sep 21 '17 at 8:41
  • Nice, updated my answer with some more background :) – Niels van Reijmersdal Sep 21 '17 at 8:49

There are (broadly) two purposes for code review: improving code quality, and disseminating knowledge.

Your developers are right in that, with their current skills, they can't really do anything for the first goal.

Which is why, for now, you should focus on the second. I'm going to assume you only have two developers (putting aside that that's too small for an effective Scrum Team...). In which case, both of your developers have a current bus factor of 1. That's a significant problem, from a business perspective.

The next important point, after the actual problem has been identified, is to bring the problem, not the solution, to your Team. Ask them if they have any ideas for solving the problem. You might find they'll come up with a different, viable solution.

If they don't come up with a solution (or only come up with untenable ones, such as 'hire more people' when you have a tight budget), then you can bring up code review, and discuss. The important part is to get the Team to feel involved in the decision-making process. This will vastly improve their buy-in.

And then, after a while, as your front/back-end developers become full stack... the purpose of the code review will start to legitimately include the quality aspect.

Of course, as I mentioned, this assumes you have a Team size of 2. If you have at least 2 front-end and 2 back-end developers (or more)... then just have them review each others' code.


The best way to introduce teams to new practises is to let them find out they need them and then let them implement it themselves. Forcing practises does not really feel self-organizing.

They still require mentoring and coaching, but they don't require "command and control."


Discussing lots of defects during a retrospective could lead to an extension of the definition of done including code-reviews.

What I would propose it to signal a problem to the team, the situation you think could be solved with code-reviews. Now let the team find a solution to the problem. If they pick code-reviews great! If they don't, but they do another experiment, great! If they don't know and look at you for advice, give them some ideas they could try. Let them decide what to try.

My experience is that the ideas of process improvements that I think are good for the team. And those that I was implementing for them. These were the improvements with the least effect. Anything they choose themselves and implemented themselves had the best effects.

Teach them how to improve their process. Just grabbing practises that worked for others is not how you solve complex processes, it leads to cargo-cult agile.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.