Can't We Just Be Nice?

[article]

It's really important to me to be a nice person. I like to be nice to people. I help out, I smile, I answer questions without making people feel stupid, and I bring treats to work. I thank teammates when they're nice to me.

I've been lucky to be on software development teams where people do nice things for each other. Today, I was struggling to get a Watir test script running. Three times in about 20 minutes, I asked a coworker to come look at something I couldn't figure out. Each time, as soon as he was standing there, I realized what my problem was. He was nice about it. He didn't make me feel stupid or as if I had wasted his time.

As I've had more opportunities to get out into the world and meet people on other teams and in other companies, I've learned that on some teams, people aren't so nice. Good people may feel pushed to the sidelines or disrespected or deliberately hurt by their teammates. They're afraid to make (or admit) a mistake, because it's seen as a failure rather than a learning experience. They can't raise any issues, because it is perceived as criticism, or they're labeled as complainers. Of course, that means they never innovate or experiment, and the team can't improve.

Testers are often the target of disrespect. Some mean-spirited developers think testers are failed programmers, rather than valuable software development team members. Conversely, testers are often mean to programmers, gloating or finger-wagging when they find bugs.

We know in our hearts and heads that if your project doesn't have good people who are allowed to do their best work, it's going to fail. The various agile development approaches understand this, but they don't all prescribe exactly the same solution. Respect for people is a pillar of Lean development (see www.poppendieck.com for more). The principles behind the Agile Manifesto mention trust, working together, support, and motivated individuals. The XP values outlined in Kent Beck's Extreme Programming Explained are simplicity, courage, feedback and communication. Extremeprogramming.org adds respect to this list. Industrialxp.org includes learning and enjoyment in its list of XP values. The Scrum community's values include commitment, openness, and focus in addition to courage and respect.

Wouldn't we naturally embrace most of these values if we just focused on being nice to each other? Being nice certainly includes trusting teammates and treating them with respect. And, if you know others respect and trust you in an atmosphere of openness, courage comes more easily. All of this helps us work together and communicate better. I know from personal experience that it's more motivating to work with nice people than with people who might hurt my feelings or tell me I've failed. If I'm not afraid to make mistakes, I'm free to experiment, starting with the simplest approach, and keep learning every day. I can fearlessly ask for help when I need it.

I was thinking about this subject yesterday when I read "A Community of Thinkers" by Liz Keogh, Eric Willeke, and Jean Tabaka. Being nice extends beyond our homes and our jobs and into our professional communities. I wouldn't be where I am today without a bunch of nice people in the agile and testing communities. I try to pay that forward every day. I've been hurt by well-known practitioners who have told me things like "You don't know anything about testing." What benefit do statements like that have? We can have a civilized discussion-even a heated one-without being rude and disrespectful.

Some of you reading this may be thinking thoughts such as: "What does 'nice' mean?"; "If I find and point out flaws in the software, is that 'not nice'?"; "That creepy DBA who never gets to our requests should be held accountable, not treated nicely"; or "However nice or not nice I am has no impact on my bonus check amount." I'd love it for every company to put high value on a respectful work environment that promotes learning, creativity and innovation--that's how companies get to be successful. And organizations are often faced with hard, not-nice decisions, like needing to fire someone who does a bad job and refuses to try to improve.

I can't make everyone behave with courtesy and civility, and neither can you. But, I can remind myself often to follow the Golden Rule, and so can you. I think it could rub off on our coworkers. Why not experiment and ask that everyone think about being a bit nicer--whatever their definition of "nice" might be?

There's much more joy in working with nice people than with a bunch of grumps who don't have time for anyone who has a question or needs a hand. It's fun to be able to propose an idea knowing that, while your team or community might not go for it, they won't slap you down for saying it. So find a reason to smile, assume that everyone is trying their best, and treat them with respect. Why not make our lives more pleasant, our work more productive, and our teams more successful by being nice to each other?

User Comments

24 comments
Anonymous's picture
Anonymous

.

March 16, 2010 - 4:19am
Anonymous's picture
Anonymous

Having experience as a developer, QA Manager, and IT Manager, my prospective on the comment about testers: "You don't know anything about the XYZ aspect of ...". This is a communication issue more than technical aptitude issue. Developers benefit from seeing products first from inception and getting the opportunity to see how it works. At the same time, they sometimes get focused on the trees instead of understanding the prospective from the forest level and are unable to understand a prospective that has less information available to them than what they benifit from. Yes QA can become technically inferior without the same rigor of developing code on a regular basis. Maybe role reversal is a good idea.<br>Remember, much of the time QA has to be adaptive, and execute on partial information, is subject to less product information in a shorter time frame than what a developer is aided by. It reasons don't end there, I can go on. Contrary to perception, most of this is not really the fault of a QA.<br>The first thing I wonder is if a develop needs to make is product more transparent. The first question I have is if QA is having difficulty then will a real user have difficulty. In what way do I need to do a better job at in communicating about my product.<br>

April 1, 2010 - 9:51pm
Anonymous's picture
Anonymous

Bill, you make an excellent point, thank you!

April 1, 2010 - 11:29pm
Anonymous's picture
Anonymous

Well, the simplicity of it all is that it is just nice to be nice, in general. <br><br>Day to day, and particularly in an Agile software development environment we face many challenges on bringing the right solution to our customers on time and under budget. Isn't it better to hae the ability to bring deliverables forth in an environment were the knowledge and contribution of each person is respected and valued. Not only by management, but also by colleagues.<br><br>Ultimately is about professionalism and not only about technical knowledge. The inability of any given team member to respect, value and collaborate with any team member will eventually show.<br><br>If we fail to comprehend the above and all else fails we should always keep in mind the concept of Karma. The person you are disrespecting and being rude to this week, may end up being your boss the next, or may hold the key to your professional success in the future. Treat others with the respect and decency that you'd like to be treated. And don't forget that disrespect can be manifested in so many ways. My rule of thumb is: If I won't treat or speak to my boss or the President of the company in the manner that I am speaking to a colleague, then I am being disrespectful, and THAT is just not professional.

June 16, 2010 - 9:32pm

Pages

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.