TOPIC: Iteration retrospective question

I am looking for some input regarding the following. A colleague of mine feels that if there is a problem or "perceived" problem on a delivery team it should be brought up in "public" in an iteration retrospective with the whole team?

Hypothetical situation: You have a talented senior developer who is an introvert and does not like conflict and when he sees a problem with another programmer's code instead of providing feedback to the other developer, often a junior developer, he just fixes the code. So he isn't sharing his knowledge and thus not providing an opportunity for that team member to develop.

Let's say a scrum master is facilitating the retropsective, should the scrum master bring this up to the whole team at the at the retrospective? Or is it more appropriate to discuss this with the senior developer individually first? I would think you wouldn't blindisde the developer with this at the retropsective unless you have discussed this with the team member and the lack of knowledge sharing is limiting the ability of the more junior members from advancing their knowledge and capabilities and is truly considered a problem?

Assume they are aren't on an XP team and they are not pair programming. But even so, would this make a huge difference?

Ineterested in what the collective intellect and experienced agile practitioners say about this.

Hi Jonathan,
I would talk with the Senior developer in person and explain him the power of his knowledge and how much value it brings to the team by explaining the corrections, to the Junior developer. This way he does not have to repeatedly correct the same mistakes. If he agrees, I would set up a" lessons learned" coffee session every sprint between all the developers so everyone learns from it.
Bringing this one in the Retrospective is right action as per guidelines but Agile is more about inspiring teamwork and considering the senior developer to be an introvert, I suggest you talk to him in person, motivate him to have sessions with junior developers rather than a retrospective meeting.
Hope that helps

Regards
Md Shahul

In my mind, it is appropriate to bring it up in either context, but why wait possibly two weeks to correct this issue? I would therefore recommend you approach the senior developer right away about it.

You are right that while this behavior is a clear violation of XP principles and practices, the argument could be made that Scrum does not forbid it, I nevertheless see it as a problem in team cohesiveness and trust.

But this issue touches many more concerns. For example, it might depend on what exactly the error is. If the junior developer is failing to follow the team's coding conventions, the senior developer may only be trying to enforce that standardization. On the other hand, if the junior developer is checking in code that is actually failing, or is logically incorrect, how is that code passing the unit tests and acceptance tests that already exist? (Those tests DO already exist, right, as you've been practicing test-first development?) If the junior developer is checking in code that does not pass the tests, then again, the primary fault is his, not the senior developer's.

So there are a lot of possibilities here that need to be investigated. But in the spirit of communication that is shared across all agile methodologies, you would want to address this immediately, rather than waiting for the retrospective. The retrospective would, however, be a good venue to share with the whole tam what was happening during the iteration, and to brainstorm and agree on ways to prevent it happening in future.