Effective communication in software development projects — in 7 easy steps

In this article I will show you how you may increase the effectiveness of communication in your projects (not only IT-related) by following seven simple rules.

eMAG’s day-to-day operations are heavily dependent on the work of Software Development department — it comes as no surprise in a business of such scale. We are present in four countries, employ about 2000 people in multiple offices and at any given moment work on hundreds of projects, many of them involving some kind of software development or technical support.

Multiple factors make up the successful project: clear vision, thorough analysis, skilful development and good management — to name a few. There is however one element, that is essential: effective communication. Seemingly straightforward, sometimes it tends to be neglected. Lack of effective communication may lead to delays, inadequate quality of the delivered results, bad code or, which is most unwanted by us, negative customer experience. All this factors sum up to loss of time and money and employee dissatisfaction.

What is effective communication?

In this article I will focus on technical aspects of effective communication — what tools and techniques you can use in your projects to yield better results and avoid miscommunication pitfalls. Looking at it from this angle, communication may be considered effective when the recipient is able to perceive the message’s meaning intended by the sender almost instantly, without much hassle. Note that the intention is important here, not the actual content of the message: the problems occur most frequently when the sender is unable to express his or her intentions clearly, so that they are understood by the recipient. Moreover, the inherent result of effective communication is that it brings closer the solution of the problem.

Take into consideration those two examples that will help you imagine this incompatibility:

1. As a developer working on a recently released application, you receive an e-mail from the project manager. In fact, you are sole recipient of this e-mail, which was sent two days ago, when you were on a vacation. Subject line of the e-mail states “problem” and screenshot of her whole desktop is pasted as the only content of the message. You have to figure everything by yourself.
2. You are a QA engineer, and your boss asked you to work on a new, quite large project. The project manager sent an invite for a meeting with marketing department and developers with nothing more than the project name inside. During the meeting, which takes three hours and includes chaotic discussion, you are asked to provide time estimate on the spot. You feel unprepared and are reluctant to this request. The meeting doesn’t end with any conclusive result.

In both cases the communication wasn’t effective. In the first example, the sender didn’t succeed to transmit the intended message because lots of questions arise in the recipient’s mind the moment he opens the e-mail: What exactly is the error? How to reproduce it? What is the intended application behavior? Additional issues prevent the case to be processed instantly: the e-mail’s subject line doesn’t provide accurate information about the problem’s nature, and (probably) it shouldn’t be sent to single developer at all — maybe rather to the team’s e-mail group or issue tracker, so it isn’t missed when one of the team members is on vacation.

In the second example, there’s a meeting organized, but its agenda is a big surprise — and not a pleasant one — for everyone excluding the organizer. Nobody can prepare themselves, do some research or relay the invitation to other person. The time is wasted on pointless discussion, which involves way more people than it is needed.

Having this negative image in mind, let’s define the general principles of effective communication. For our needs, the essence can be boiled down to those four points:

1. The problem is easily identifiable — the recipient can easily know what the message is and what is expected from him.
2. The message is explicit — there is no place for ambiguity, it can to be understood in only one way.
3. It is properly targeted –the e-mail (or other communication device) reaches those people or teams that need to be involved, without unnecessary forwarding or delays.
4. It saves time and other resources — which comes from previous points.

Now let’s see how — by employing just 7 simple rules — you can enhance the effectiveness of your communication.

Rule 1: Make your e-mails clear and properly aimed

E-mail is the most common tool of business communication for more than fifteen years, still lots of people are not using it at its top efficiency. To back this claim, I ask you to look at your inbox and consider how many of the messages allow you to figure out their contents just by looking at the subject line? And even if you open the e-mail, is each of them clear and straight to the point, or you needed to ask some extra questions or do some research to clarify the issue? Are there e-mails that have dozens of recipients, but only one or two of them really need to take some action?

Bear this experience in mind next time you write your e-mail. Imagine that you are the intended recipient. Will he know just by looking at the subject line (for example on his mobile or desktop notification) what the e-mail is about? Did you catch the meaning of the communication precisely in those few words? For example, instead of “error!!!1111” when reporting some server problem, consider using following subject line: “Disk quota exceeded on server srv42”.

Then, think about the contents of the e-mail. Does it precisely state what is the issue and what action do you expect from the recipient? For example, it is common mistake to omit in bug reports essential information, such as steps to reproduce error, expected behavior or URL of the problematic page. Project manager must be sure that every person who might report an issue knows what information the QA or development team expects.

All the effort of crafting the precise message is lost when it goes to the wrong recipient. Put those people who need to take action upon your request in the “To” field. Others should be included in the “CC” field, which states that their involvement is not required. It is a common mistake to send some request or bug report to a single team member (who might be busy or on a vacation), instead of mailing the whole group or — which is a preferred solution in many workflows — special e-mail alias that creates Jira issues from the incoming mail (this is the solution that we use in eMAG).

All these hints will make your e-mail communication a lot more clear and comprehensive, yielding a better, quicker response.

Rule 2: Leverage the power of issue tracker (and other integrated tools)

The first hint regarding the issue trackers is: just use them! Surprisingly, many teams or companies still rely on other forms of communicating tasks, such as e-mails, Excel files or Google Docs spreadsheets. Using the specialized tool greatly improves productivity and allows better management of the tasks.

Here at eMAG we use Jira (https://www.atlassian.com/software/jira) integrated with other tools from Atlassian’s suite, offering great flexibility and lots of options, which is important in a company with dozens of teams working on diverse projects using various workflows. There are of course plenty of other solutions (https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems) to choose from.

The issue tracker serves as a tool with several functions. The most important is the ability to track tasks’ status and history. People who want to know what is the progress of a given job don’t have to come and ask around or send e-mails — they can just check into Jira. As we in eMAG work in Scrum, our issue tracker has additional options to track the progress of the sprints and contents of backlog. This way, Jira is for us the unified tool to organize our daily work.

Another function of issue trackers is managing and reporting. Managers can see what tasks are being worked on currently, what was done and what is pending. We can also generate reports that show us how the organization is working on a global level.

If you want the work to be done properly, remember about the important rules of reporting the issues:

1. Make the task title as meaningful as possible — ideally it should be enough to see it to understand what the issue is about.
2. Put only one thing in one issue. If you have multiple bugs to report — use separate issues.
3. Use relevant attributes (e.g. environment, application name, etc.) — depending on your organization’s workflow.
4. Include as much information as possible, so it is easy to understand and reproduce the problem: what is the nature of the error? What is actual and expected outcome? Add screenshots, URL of the webpage causing trouble, test data that you used, etc.
5. Be extra careful when your organization’s workflow includes creating issues by sending e-mail to some specified address — have it in mind when describing the problem, adding the attachments, etc.

It is always a good practice to add comments, progress reports and other useful information to the task — so even after some time its progress and outcome can be reviewed and used in other similar situations. There is no point in a task being closed without a word of explanation.

Rule 3: Organize your meetings wisely

Meetings are quite often subject of corporate jokes. They take lots of time with participants dozing off, playing on their phones, writing e-mails or doing other activities to kill time. In general, they are perceived as massive time wasters.

When you’re the one in charge of organizing a meeting, do it wisely. Don’t invite every person who may have something in common with the project. Think about what relevant input each participant can add to the meeting and pick only those who are necessary.

Agenda is an essential part of every meeting. It gives proper structure for the discussion and participants can prepare themselves before attending, or they can assign some better fitting colleague to take their place — so always remember to prepare and send the agenda in advance.

When considering the list of participants and agenda, bear in mind that it is better to split the topic into series of smaller, more focused meetings rather than one big status meeting. Nobody wants to sit through some long session to be only involved for ten or fifteen minutes. People are feeling disrespected if you don’t have consideration for their time.

Scrum — the agile methodology that we use in eMAG — gives great structure for meetings (called “ceremonies”), so they are informative, focused, time boxed and their agenda is known well in advance. Every member of the meeting comes prepared, knows his or her role and is focused during the whole meeting. If you are considering introducing Scrum in your organization — this is one of the major benefits.

Rule 4: Maintain common dictionary and retain knowledge

eMAG is a multinational corporation with offices in four countries, each of them having a different culture and language. We’re even split between the two time zones.

In such environment, having a common way of communication is very important. It doesn’t mean just that we all communicate or document our work in English language, common dictionary is an important concept that allows different people, coming from different backgrounds, education or experience, to work on the same projects. At the beginning of a project or initiative, you need to declare the basic concepts — their names and definitions — so there is no place for ambiguity. Some of the examples of this rule in software development are common code style guide, naming servers or applications in unified way or having procedures for most frequently occurring tasks.

Other thing that supports mutual understanding — not only in software development — is good documentation — functional and. more importantly. technical. Knowledge of the project — its design, procedures, how-tos — is often stored in people’s minds, but as they come and go, the knowledge is not retained. New team members have to learn everything from scratch and ask around.

The grisly but accurate metric of how much you will be in trouble is the “bus factor”. It measures how many team members can be unexpectedly removed from a project (here: hit by a bus, but you may understand this as leaving the job, having a vacation, switching projects, being sick, etc.) before it halts due to lack of a knowledgeable person. In worst case scenario, this factor equals to 1, when there is only one engineer who knows how the given component works and is operated. Preparing good documentation (among other techniques) is a way to increase the bus factor to desirable values higher than one.

Rule 5: Use instant messenger

This may sound obvious, but I saw some companies that rely only on e-mails and telephones in their electronic communication. Messenger is a great compromise between the instancy of the phone and unobtrusiveness of the e-mail. It’s perfect when employees use the same IM with built-in address book, so they can contact each other easily.

In eMAG’s software development department we use HipChat, which allows us to create rooms for teams, projects or even ad-hoc discussions and provides an easy way to engage everyone who is required. For example, when we have some deployment to do or decision to make, we create a separate room and invite all people involved. This is especially useful when employees from different eMAG’s offices are working on the same issue.

Rule 6: In-person communication beats anything else

It is a fact: we get the best results when we can meet in person and discuss the issues. Communication through the e-mails, IM or phone always leaves some room for misunderstanding or unnecessary delay.

The communication is most effective when people know each other, had the possibility to talk face to face (preferably grab a beer or two and chat about some non-work stuff) and can work on projects by meeting in person. This is the best recipe to resolve any issue.

Of course that in a company like eMAG, which spans across several offices and has multinational projects, this is not always possible. The distance makes communication more challenging, but not impossible. To remove those impediments, we schedule frequent calls (preferably with video transmission), preferring them over dry e-mail communication. When it is needed, we also travel between the offices to create the relationships and work on the big issues. Evening visit at the bar is a must, so people can get to know each other personally in a less formal environment :)

Another solution that is worth considering in the multi-office organizations is establishing ambassadors — people who have an extra role of acting as representatives of the remote office. The name says it all, as they can be compared to a country’s ambassadors — if there’s some issue that has to be taken care of — they are there to help by personally contacting the required employees.

When contacting people in person remember not to use this privilege frivolously. Anyone — and especially a software developer — needs to focus on his work and it’s impossible when interruptions are frequent.

Rule 7: Don’t force the rules, show the benefits

As aconclusion, the question that may appear is: how to introduce these rules in the organization? Some managers are tempted to do it forcefully. On the other hand, employees who do not hold the managerial power feel that they don’t have an impact and cannot change their colleagues’ way of thinking.

Both attitudes are wrong. Introducing change in human behavior isn’t a task of ordering them to start behaving differently from now on. The only way to success is to show them the benefits of acting in a certain way and act as an example. This can be done by managers and other employees alike. People are reluctant to change their habits if they don’t see a purpose of their effort. Only when the advantages are noticeable one may encourage others to copy this behavior by further explaining the ideas — by causally talking about them, preparing presentations, workshops, etc.

Remember that changes take time to happen, so don’t be discouraged if you can’t see the results instantly. It is only your determination and example that can make things happen.

Conclusions

In the final words of this article I would like to underline that these are just basic concepts of effective communication. They are a good start in the efforts of streamlining the cooperation or as an introductory material for employees entering the company or team. By customizing and expanding them, you can tailor the methods so they fit your organization. Good luck! :)