How open team members should be ?
I have a problem with openess within the team. I am "too open". Other team members are not willing to be so open. For example I said that the other team member is not competent in what he is doing. Maybe I exaggerated a bit. I said "sorry" but it seems not be helpful. That person lives in other country. What should I do ? I am planning to ask his manager from other country to be mediator, becuase I would like to have good relations with the others.
On several occassions people are telling me that I am too straightforward and I just say what I think. I should be more diplomatic at work. People usually say good things in front of you but gossip and say bad things behind your back. I am trying to do the opposite - say the true in front of the person and say good things behind the back. This is just theory.
Forget my personality. Do you have any guidelines - how open person should be in the scrum team ? I guess we can do nothing if someone do not want to share details of their work in front of the colleague from the other country.
Openness is one of the Scrum values, there are others including respect.
What do you think about “productive dissent”, and how the Scrum values might help achieve such a balance in your team?
I have a problem with openess within the team. I am "too open". Other team members are not willing to be so open. For example I said that the other team member is not competent in what he is doing. Maybe I exaggerated a bit. I said "sorry" but it seems not be helpful. That person lives in other country. What should I do ? I am planning to ask his manager from other country to be mediator, becuase I would like to have good relations with the others.
Don't mistake open[ness] for impolite[ness]. And whilst it is true openness is expresly listed as a Scrum value, it is in fact a value that can be universally embraced.
Would it be worth rephrasing some of the points you (would like to) make? Instead of saying "the other team member is not competent in what he is doing" (which, to me, is nothing more nothing less than an insult), you could try to communicate and understand the other person. So rather than jump to conclusions, look into the background.
Openness is not an excuse to be rude. There are many ways of communicating unpleasant things that are not perceived as rude. I'm going to go real old school and suggest books like "How to win friends and influence people." The fact that book has been around for ages just supports that the way communication happens is important.
That person lives in other country. What should I do ?
Learn more about their culture. What is acceptable in your country may not be in other countries. For that matter what is acceptable in your town may not be acceptable in others.
To me the openness in Scrum is more about being willing to share any information you have with anyone. Be open to others disagreeing, others having different perspectives. Yes, a highly functioning self-organizing teams should be able to have difficult discussions if it is felt someone is not doing work that the team feels is quality but it shouldn't be confrontational. Telling someone that they are incompetent is pretty confrontational. Those kind of discussions should be done in private or, at most, with a manager or HR representative present.
Yes, I agree that saying to the other person that he is incompetent is impolite and rude. I have not said to this person directly. It was passed via colleague. Anyway I said sorry. I cannot explain now all the details. The work for me was frustrated. This is not excuse for harming people. On the other hand managers should not force me for doing frustrating work. For example, I am testing and reporting bugs which no one is going to correct. Does it make sense ?
I do not want to share my inter-personal problems here. I wanted to ask about openess. If we had planning meeting or discuss the work earlier together then possibly there would be less frustration. The other software engineer refused looking at the code together. He said he will manage himself. In such case I cannot force the other person to share his work with me if he doesn't want to do so.
I said "sorry" but it seems not be helpful.
Why did you feel the need to apologize? How did you apologize?
In reading your post, it doesn't seem so much a question of openness, as it is a communication issue between you and another team member. And without any additional information, I am inclined to think that this is not an isolated incident.
Instead of being very direct and overly-critical, did you give any thought to how you could help this team member? Instead of "observing" that the team member is struggling, how can you (and the rest of the team) work with bthis team member so that they don't struggle?
Well, I feel need to apologize in order to maintain relationship. It is a new thing for me, that even if someone feels injured or do not want to talk to me, saying "sorry" or asking for forgiveness may not be helpfull.
The point here is that I was disappointed with the result of two months of technical work they were doing. I thought that in effect we will have less bugs. It is not the case. The managers even told "not to correct bugs which existed in previous version" ! We wait until customers will report them. Luckily human life does not depend on our software. I was blamed for "tending to perfection".
I don't know how to communicate disagreements with the others way of working and in the same time still work together.
I thought that in effect we will have less bugs. It is not the case. The managers even told "not to correct bugs which existed in previous version" ! We wait until customers will report them.
I came to Scrum Master from a 15+ years of Quality Assurance. When I first started I had the view that every bug found had to be fixed. Then I started looking at the bugs that were found and compared them to the actual way the products were used. What I discovered is that a LARGE number of the bugs found were not in the 80% use flow of the applications. If that is the case what is the urgency in fixing the bug? If it won't cause catastrophic damage if encountered, is it really worth fixing if the chances of encountering it are minimal?
Every piece of software that is generally available will have bugs. That I can guarantee because I am able to find bugs in just about every piece of software I have ever used. (Yeah, bragging a little bit). I actually agree with the "wait until customers report them" for bugs that have been knowingly released. My assumption is that the bug's severity and likely hood of being encountered have been assessed and found to be acceptable. So why do work that isn't absolutely necessary? The following is one of the Principles found in the Agile Manifesto for Software Development that I believe is the most important. It is third from the bottom.
Simplicity--the art of maximizing the amount of work not done--is essential.
Agile/Scrum will not improve code quality on it's own. That is up to the Development Team to make happen. But if you adhere to the premise of only writing code that is needed, the bug counts could be reduced by virtue of reducing the lines of code and unnecessary complexity.
In the specific case you have mentioned, I suggest that an effective way of communicating might be to inspect the premise of your issue and determine the legitimacy of it. I honestly believe that your premise in this case is flawed and you could in fact be wrong in your opinion.
I admit that I might be wrong. In such case what have I learned from this situation ? Maybe the first time I was not quiet but I have expressed loudly my opinion. I am a bit afraid of myself. I feel like I was half-died and I risen to life. Is it a change for better ?