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

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!