Senior developers dont trust the quality of code produced by mid and junior devs#

A redditor asked the following question:

Question#

Hey fellow scrum masters,

My team currently has the problem that there is a strong difference in development experience between developers. These differences are causing tension as quality expectations are not being met.

The team consists of 2 senior developers, 2 junior developers and one who is in between the two levels.

Most recently, the 2 junior developers and the “mid” developer have been working on a pair programming task. The problem that came up now is that the senior developers were not satisfied with the code that was created and have much higher expectations of pair programming that is done by experienced developers. Basic principles of software development are disregarded. The experienced developer who supervised the two junior developers should have known better.

Besides the obvious measure to involve the senior developers more in the pair programming, I would be interested to know how you would proceed in such a situation? What measures would you implement to resolve the tensions?

The senior developers have expressed that they can’t trust the code quality that comes from pair programming the 2 junior developers and the “mid” developer.

My suggestion#

The difference in skill level is normal. In my opinion, the problem here is that senior developers are behaving like juniors. I don’t know how long a solution produced by a junior and a mid took, but if everything has to be done from scratch, it’s not the problem of those two people, it’s the problem of the whole team.

Both senior developers failed because they allowed waste and rework. Or rather, the whole team failed because they didn’t act as a team. Now you all need to sit down and think about what you need to do to make sure this situation doesn’t happen again.

I am a Senior Developer and Scrum Master. I believe it is the responsibility of the more experienced to teach the less experienced, preferably by working together. The way you work is also important. If the rejection of work happens at code review, it means that code review is a quality gate in your process, rather than quality being built into the process.

In my opinion, code review when development is potentially complete is far too late. What you can do is teach the team to work together and break the work into as small pieces as possible to get more frequent feedback. Then, even if some development is rejected, the batch size is small and the cost is not high.

They can also try to validate quality before the code is finished, for example when two developers have an idea, they can discuss it with the rest of the team and gather feedback earlier.