Collaborating with Outsiders to the Dev Team
Editorial Note: I originally wrote this post for the SmartBear blog. You can check out the original here, at their site.
Developer news sites, blogs, books, and tutorials tend to speak at length about how developers should collaborate with one another to maximize team effectiveness. The subject of how developers should collaborate with people outside of their team often gets shorter shrift, however.
Personally, I find this to be a shame. I think it tends to reinforce the stereotype that developers do a poor job of human interaction and need an organizational layer of people to translate between them and normal humans. I would prefer to live in a world where people didn’t draw distinctions between “the developers” and “the business” because it was simply assumed that software development was part of the business.
For this reason, I’d like to offer some thoughts on how you, as a developer, can most effectively collaborate with non-developers — people outside of your team. I will offer the caveat that some teams, particularly Scrum teams, are cross functional and thus include non-developers in the team itself. I understand that, but for the purpose of speaking to the broadest audience, I will presuppose that your team is specialized in the sense that it is made up exclusively of software developers. Besides, if your team does include other disciplines, it isn’t as if advice on how to collaborate with those folks magically becomes invalid.
Before getting into specifics, I want to mention two universal principles. The first I will call out only briefly now and not again because it should be common sense and go without saying. But, in case it doesn’t, treat these colleagues with courtesy and respect. They are intelligent knowledge workers that simply have a different specialty than you do, and you ought to treat them as such. If you can’t do it simply as part of being a decent human being, do it because acting like a primadonna is career limiting. The second principle I’ll mention is that, because these collaborators are intelligent knowledge workers with a different specialty, you should endeavor to learn from them to improve your own work.
Quality assurance folks (i.e. testers) probably collaborate with developers most frequently. Developers write code, and QA tests the result. It’s a paradigm with which we are, no doubt, all familiar.
By its nature, however, there is a natural tendency to want to shoot the messenger. You spend all of your time building a beautiful implementation only for your QA colleague to mercilessly point out all the mistakes you made while doing it, so sulking or lashing out may come naturally to you, if unbidden. Resist this impulse, first of all. It’s not professional. Instead, take this feedback in stride by realizing, “better my colleague in QA discover this mistake before a user does and thinks I’m an idiot.”
But your collaboration with the QA folks should go much deeper than simply not snapping at them. QA will wind up signing off on your application after running it through the paces, so, make yourself more efficient by going to them before doing your development. Ask them to show you how they’ll know when the code is good — what tests it will need to pass. Armed with this knowledge, you can leverage their keen eye for issues to guide your development. As an added bonus, enlisting them up front will help you start to reason about an application’s performance with a more removed, more critical eye.
In most organizations, business analysts (or perhaps project managers) assume responsibility for communicating requirements to the development team. On top of that, they may also hold responsibility for timeline management, scope decisions, and prioritization.
This is another relationship that can be needlessly contentious, particularly when flaps emerged about whether the software, as written, satisfies the requirements. Developers will often view BAs as middlemen between them and the bosses, while the BAs will regard developers as easily-distracted geeks that need babysitting. But you can easily avoid this.
Adopt the stance that the BAs offer you two powerful things: crystal clarity about what your company wants the software to do and a path of insight into the broader business strategy. The former is achieved by adding the BA to your up-front pow-wows with the QA folks in what is sometimes called a “three amigos meeting.” Developers, BAs, and QAs all start the feature/project/whatever with a clear definition of what it will mean to be done. The second powerful offering from the BA is insight into the business, and it is achieved simply by picking their brain frequently to understand the strategy of how the software will be used, to whom it will be marketed, etc. By better understanding the business case for your software, you can offer more insightful suggestions during the course of development.
In my travels, I have frequently witnessed pockets of discord between developers and QA/BAs, but I cannot really say the same about developers and UX people (not to say that it never happens — it’s just less common). This relationship tends to fall into dysfunction by virtue of being too disjoint and asynchronous. You see this most commonly in the form of UX people creating elaborate wireframes and mock-ups only to move on to other things long before the developers ever see and implement them. Any collaboration or iteration fails to exist.
As such, your path to improving the collaboration makes itself fairly obvious — have it in the first place. Your organization’s structure may present difficulties, but certainly nothing stops you from wandering over and asking for a few minutes of time. Ask them about the philosophy behind certain decisions. Have them show you production examples from previous projects so that you can see the concept come to life. Gain an understanding of which design decisions are core and which are peripheral to help guide you when you must adapt on the fly.
If you can go beyond that, then absolutely do. If possible, collaborate with the UX folks the way you would if they were the producer of a yet-unfinished, internal API and you the consumer of it. Implement something using their stuff, seek their immediate feedback, and adjust accordingly (both of you). Beyond picking up an understanding of UX that you can carry throughout your career, this will help you more closely realize the actual vision for the product and do things that delight the users.
A Common Theme
I’ve listed three common collaborators with software development groups, but there are plenty of others: managers, users, DBAs, operations, etc. Perhaps you’ve noticed a common thread here, as I’ve talked, which is that of syncing up as early as possible and getting as much feedback as possible. That’s no accident. That same theme can and should guide your interactions with any of these other, unmentioned groups as well.
One of the most frequent sources of failure I’ve seen in software projects is operating for long periods of time without meaningful feedback, only to hope that everything works out magically at the end. Even if your company operates this way, don’t do it yourself. Bring people in, respect their opinions, value what they have to teach you, and, above all, get and incorporate feedback. The world moves too quickly these days for you to sit and code in a bubble for months on end — collaborating with all interested parties is no longer optional.