What's in a Name? Everything.

[article]

Perhaps the real problem is that we don't know what our parts are. We don't have agreement about who's doing what. But we think we do because everyone has standard titles. These titles have become a kind of shorthand. Everyone knows what the Quality Assurance group does, right? We don't explicitly define the scope of responsibility of the groups because we think we already know. Unfortunately, we also often have very different expectations.

A "Senior Developer" doesn't have "Test" in her title. So should she be responsible for testing to make sure the changes she just made in a shared piece of code will work with the other pieces of code? If you ask the testers, they'll probably say, "Yes! The developer is responsible for making sure that her code plays nicely with others." If you ask the developer, she's more likely to say, "I'm not a tester. I made sure my stuff works; it's up to someone else to make sure everything works together."

Some organizations solve the problem of no one taking responsibility by creating positions that bridge the gap. A new job title. Someone who can truly own that piece of the puzzle. When it works, it's an excellent solution. Unfortunately, sometimes it becomes a crutch when other members of the organization shift more and more of their work onto the new bridge organization. Maintenance engineers become responsible for almost all bug fixes so the other programmers can focus exclusively on new code development. Integration engineers become responsible for unit testing. External beta testers become the sole source of use case testing. Will forming a new group work in your situation? Maybe. Maybe not.

Perhaps the most powerful question anyone can ask is, "If our development process worked really well, what would it look like?" In answering that question, and in combining answers from many different areas of the company, you can get a clearer picture of where reality isn't meeting expectations. Then you can work to address the difference between reality and the idealized process. If their expectations are unreasonable, you can negotiate.

So what's in a name? There may be a bushel of expectations and a barrel of responsibilities, not all of which you might think you signed on for when you took the title. Make the expectations and the responsibilities explicit. After all, your title might not mean what you think it means.

About the author

Elisabeth Hendrickson's picture Elisabeth Hendrickson

The founder and president of Quality Tree Software, Inc., Elisabeth Hendrickson wrote her first line of code in 1980. Moments later, she found her first bug. Since then Elisabeth has held positions as a tester, developer, manager, and quality engineering director in companies ranging from small startups to multi-national enterprises. A member of the agile community since 2003, Elisabeth has served on the board of directors of the Agile Alliance and is a co-organizer of the Agile Alliance Functional Testing Tools program. She now splits her time between teaching, speaking, writing, and working on agile teams with test-infected programmers who value her obsession with testing. Elisabeth blogs at testobsessed.com and can be found on Twitter as @testobsessed.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03