What a Scrum Master can learn from “How to win friends and influence people”
Buy it now
One Minute Bottom Line
|A Scrum Master can improve requires good communication skills, and there is always room for improving them a little bit. Find out what a inter-war salesmen can teach us about properly dealing with people.|
When working as a Scrum Master you have to constantly make sure the Scrum principles are followed, but there are also other aspects that requiring handling as well, and they are more subtle yet equally important for successfully managing developing teams.
I am talking about soft skills such as managing team conflicts, encouraging people, knowing how to challenge your team members. There are times when some of your guys behaves inappropriately versus others, or their attitude/behavior is counter-productive and you have to step in and correct these problems with diplomacy and keen tact.
If you are not endowed with people handling skills, don’t despair, there is still hope. I don’t believe those telling these skills can’t ever be acquired and that you have to be born with them. With proper training you can improve yourself sufficiently enough to be able to manage your team efficiently,
So, I will present you a great book, offering old solutions for our newer problems.
Dale Carnegie wrote “How to win friends and influence people” in 1936, and it contains many real life stories, each one concerning a particular situation and a solution on how the author or one of his students managed to handle it.
“Don’t criticize, condemn, or complain. (It rarely helps the situation).”
This is a great tip. Everybody has an ego, so condemning and criticizing will just make someone resentful and demoralized. First, you have to be sure you’re not wrong, and don’t follow you’re impulses. Then you have to be subtle and diplomatic in how you convey your disapproval, remember, you’re working with highly qualified individuals that can get your message even if you say it nicely.
“Give honest sincere appreciation.”
Most of us know to draw someone’s attention when things are not turning the way we planned, but when things are working, we should also show appreciation for those that made it so. Appreciation is maybe the best reward someone could get for their good job, and be sure she will strive to keep up with her reputation she know earned.
“The only way to get the best of an argument is to avoid it. (Because even if you win, you aren’t going to get what you want.). Let the other person save face.”
Fighting and arguing won’t get you the result you’re aiming for. Even if someone will follow your order or will accept your complain, he’ll do it resentfully, while accumulating frustration. A bad mood makes anybody counter-productive, especially in software development, so your goal is to deliver your message in a nice friendly way.
If you happen to correct someone’s actions, then you have to do it on a one-on-one meeting, because throwing on him your bad thoughts in front of the whole team will diminish him, and that’s always disrespectful and inconvenient.
“Show respect for the other person’s opinions. Never say, ‘You’re wrong’. If you are wrong, admit it quickly and emphatically. (A good way to start is to admit that you could be mistaken.)”
I’ve been wrong so many times, even when I could have sworn I was right, so now I must give a lot of thought for someone-else opinions or ideas before start debating. Even if you know your colleague is wrong, you don’t have to say it up front, because his natural response would be to step back and fight his idea. Instead ask him questions and challenge his idea until he realizes and admits the fault himself.
When being wrong, have the courage to admit it, it won’t ever make you look bad, instead, it will make you look human and the others will understand there’s no fear in erring. This builds trust in your team and that’s where you’re heading anyway.
“Try honestly to see things from the other person’s point of view”
To be a great conversationalist you have not just to learn to listen but to put yourself in the other person’ shoes. Seeing things from her perspective, understanding the context of her actions will get you a better insight into her problem, and will provide you more input for choosing the right solution for her problem.
If a junior developer did something bad, try to remember how you’d have done it when you were a beginner too, and how you’d have wished to be helped by your back then leader. “Throw down a challenge. (Do this when all else fails.)”
When developing a certain product it may be a good idea to also present your competitor solution, and therefore trigger the competition impulse in your team. The winning promise is a great stimulus and if you manage to win the race, then you owe your team a well deserved payoff (take them to a great trip, throw them an unexpected party, just think with your heart what’s the best reward for such an effort).
I have only scratch the surface on this topic, there is more to learn from this book than I could ever cover in a short article. My only regret is that I wished I’d had the chance to read it when I was a teen, as maybe I could have embedded them so much earlier.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)