Nowadays, a lot of software development takes place across organizational boundaries. Communication between these boundaries is essential if you want to deliver a reliable application within the required time frame and with the fewest usability issues possible.
“As you all know, we're having a bit of a problem here right now. The aforementioned problem being that you keep trying to beat each other senseless with blunt instruments, banging up against the bulk head, pounding, mugging, jumping and generally carrying on cranky. And while some of the other species wouldn't mind if you wiped each other out, even they would prefer that you did so quietly.”- Ivanova, “The Geometry of Shadows,” Babylon 5
At one time, a single developer working late at night could create an amazing application—assuming the developer had access to enough pizza and soft drinks. Today, most developers work within a development team. That team may cooperate with other development teams in an organization and most certainly it interacts with stakeholders (people who have, or will have, any sort of commitment to the project) in other departments.
Anytime more than one person is involved in a project, communication becomes vital in ensuring that the project succeeds. Because mindreading hasn’t been perfected yet, it’s important that each stakeholder communicate thoughts clearly and concisely in a form that everyone else understands. With that, here are 10 common communication issues that developers face and some ideas on how to deal with them.
Establishing Communication Goals
One major problem is that vocal members tend not to establish specific goals early and less vocal members never make any contribution at all. As anyone who’s paid close attention to a social gathering knows, the discussions can veer from topic-to-topic without any sense of purpose or direction.
Unfortunately, many discussions in which applications are brainstormed and designed follow this same course. As part of the initial meetings that define the need for an application and its requirements, a group leader needs to discuss and set communication goals such as:
- Inform: An essential part of any communication is to inform others about the requirements of the application from every stakeholder’s perspective. Nothing is accomplished without people having enough information to make good decisions.
- Engage: Good communication engages everyone involved in the process and elicits feedback. When the stakeholders begin nodding off, looking at their phones, or drawing silly pictures on their notepads, it’s time for a break. Try to focus the information in a manner that makes it understandable, relevant, and interesting. (This may involve cat videos, but what’s wrong with that?)
- Listen: Every member must listen to the person offering information - this means comprehending it as well. Everyone must be free to ask questions. Use active listening techniques to ensure everyone understands what each stakeholder is saying.
- Persuade: Compromise, or at least accepting trade offs, is part of every development effort. Each stakeholder must present a persuasive argument for a particular need so that the development team and users can make the software meet expectations and user needs.
- Advocate: If you have multiple stakeholders (and most of us do), success means getting multiple opinions on a course of action to meet specific needs. Management must be prepared to promote one particular course of action, with an eye to the organization’s needs. Of course, management also needs to listen to each solution and to fully discuss the options before advocating a particular solution.
- Rally: Communication is not just posturing or announcing your view and then ignoring everyone else (even if some corporate meetings appear as though they come straight from a Monty Python skit). It also involves meeting the team’s emotional needs. Encouraging and motivating other group members is the responsibility of every stakeholder. A positive atmosphere always works better than one filled with contempt for others.
Developers within the team must communicate effectively with each other. Teams made up of people with similar interests and skills are called homogeneous teams, while teams made up of diverse groups are called heterogeneous teams. Overall, the diversity in a heterogeneous team is great: The team has access to more skills and perspectives with which to make intelligent decisions.
However, diversity can also cause problems; team members may not know how to express ideas to people with a different background. The most common differences include:
- Skill set (such as languages each developer knows)
- Personal biases
- Environment (such as where each member grew up)
Differences in language, past experiences, and viewpoint make it harder for team members to understand each other. Both verbal and non-verbal communications differ between groups. The person who speaks with a Boston accent may not be able to understand the team member from India. Someone from England may use terms that an American won’t understand. (As Sir Winston Churchill was quoted as saying, “Britain and America are two nations divided by a common language.” Though, for the record, there is some discussion as to whether this quote actually came from George Bernard Shaw or Oscar Wilde.) The one female member of a team will very likely have a different perspective on many matters than the stodgy male.
Even differences in the computer languages that each team member knows how to use can cause problems. Imagine trying to explain a complex class using C++ code when the other team members only know how to work with C# and Java. Yes, the three languages are similar, but there are enough differences to cause problems. Using a block diagram that discusses the concepts in concrete terms can provide better communication. In fact, anything you can do to move a conversation from the realm of the abstract to the realm of the concrete is good. For example, Apple is famous for using a desktop metaphor to transform the abstract world of computer applications into something people can understand.
However, what’s more important is that you emphasize the similarities between team members, whenever possible, to build a partially homogeneous team. When this tactic fails, emphasizing how the contributions of one team member augment the contributions of another can help build a team spirit: The two members working together create a greater whole. The team leader is tasked with ensuring none of the team members feel isolated. Make sure you’re inclusive in team activities and ensure that you consider minority member needs, wants, biases, and preferences.
Some people want to rule the world, but failing that, they want to rule a group. (“University politics are vicious precisely because the stakes are so small,” said Henry Kissinger.)
Every organization battles fiefdoms. A manager or other employee can easily decide that the group won’t share resources or do anything else that’s perceived as a loss of power. The problem becomes more pronounced when groups with the same goal attempt to work together, such as two development teams in different parts of the organization. In order for application projects to succeed, each stakeholder must be willing to give up some autonomy and power for the good of the group, including sharing resources.
In some cases, management needs to step in to enforce specific levels of sharing, but often peer pressure is enough to break down the walls. The goal is to maintain stakeholder group cohesiveness, while ensuring effective communication and resource sharing between group members. At the very least, you want to keep people from hissing and spitting at each other, preventing the software from being built and generally carrying on crankiness.
Stakeholders Don’t Know What They Want
Developers need to know what stakeholders want. On the other hand, stakeholders don’t necessarily know what they want, and they take for granted “obvious” information that developers don’t know. At a minimum, developers require documentation that discusses the requirements. It offers a stable target for anyone working on the project, and helps the user community figure out what they need and what they want (assuming these two things are related). Requirements Traceability: Why Bother and Requirements: Not Just for Application Projects may be helpful resources.
Differing Frames of Reference
Everyone involved in a project has a different frame of reference—a different way of viewing the problems resolved by an application. Using technical terms, pseudo-code, and other non-graphic communication methods usually clouds the issue, rather than clarifying anything. Instead, draw a picture that other group members will understand. Visualization helps because people tend to think concretely and graphics are a concrete method of expressing abstract ideas and concepts.
However, you need to go even further. When a development team doesn’t fully understand a problem, it can’t provide a solution. Sometimes it helps for the other stakeholders to physically show the development group why a particular solution won’t work. For example, sitting a developer down in front of a terminal to try performing a task is usually more effective than simply describing the problem. (“See? Doing it that way takes five minutes for every one of these 200 records.”)
Time to Talk versus Time to Work
There’s a perception among developers that applications are delivered on time only when the development group writes code, rather than when team members spend time in meetings or in conversations. Meetings do take up a lot of time, and using other communication methods can help reduce time-wasting endeavors.
However, in order to create a great application, developers must spend some amount of time talking, or they can go down the wrong path. Consider using these communication techniques to avoid wasting time in meetings, yet getting enough talking time done to make the project a success.
- Use texting, instant messaging, or Internet Relay Chat (IRC) to discuss issues of immediate interest in a small group. (Here again we see some diversity, in this case in age. Four in ten of the respondents to a recent reader poll of mine say that they use texting for quick communication. The younger respondents were more likely to use texting. Older developers might choose a different tool.)
- Use e-mail to discuss less important or less time-sensitive issues with a medium-sized group.
- Create a forum or other large group site to discuss issues with everyone involved.
- Develop a wiki to allow stakeholders to create resources that fully explore and refine the application requirements.
- Set aside “talking time” – such as the Scrum meeting advocated by some Agile developers – and development time, during which programmers and testers leave one another alone for creative work except in case of emergency.
It’s essential to democratize communications. Each project member should feel free to contribute ideas. Otherwise, the stifled group will feel that its needs and wants aren’t represented in the final product, and they may not even use the software because it doesn’t meet their requirements.
In some cases, this means someone must draw out the opinions of the stakeholders - including the quiet ones, the introverts and the passive-aggressive – through various means, such as anonymous contributions. However, at some point, everyone needs to take responsibility for his contribution toward the project. It’s a balancing act, which is why good managers are so valued.
The Need versus Want Confusion
A need is something that an application must provide in order to be successful, while a want is a nice-to-have feature that enhances the user experience in some way. In some cases, a stakeholder fights hard to maintain every need and want that group envisions for the final application. In order to make progress – for budget or time reasons – often the organization must put aside some wants to ensure that every need is met.
Sometimes, a stakeholder confuses a “want” with a “need” and can’t persuade the team that what they want really is required. Management must step in to advocate a particular course of action and rally the group as a whole to pursue the approach that best meets the needs of all stakeholders. Of course, management has to be subtle in addressing this issue. Sometimes it’s easier to discuss a sticky issue over beer and pizza than to listen to the screams of two alpha managers in a meeting room.
Because developers are so familiar with the software they build, and the process of creating it, it can be impossible for programmers to make any sort of assessment about the code’s viability - a fact that QA testers know all too well. Developers need real users to interact with the application and to provide feedback regularly and consistently.
For feedback to be effective, it’s essential to:
- Make the user a first-class citizen in the development effort.
- Ensure that the users participating in the application design are representative of the people who actually use the software.
- Acknowledge the users’ perspective. Give them full attention. Show them how the developers are actually implementing user suggestions.
- Provide a feedback loop by showing users the development team’s application progress. Discuss technology and project limits in terms that users understand (“Adding this feature will add two weeks to the project and several thousand dollars to the budget”), and then accept their input on issues.
- Constantly communicate ideas, application changes, and technological developments so that users remain informed about progress and issues.
Lack of Involvement
In any sort of group activity, some participants try to get a free ride. They claim to be involved, but they never seem to add anything, or even to listen. (Then, among the most irksome, they try to take credit for a project’s success.)
But in a truly successful development effort, every stakeholder must remain involved and committed. If you’re affected by this software as user or creator, you should review the application constantly and provide feedback about it. If you aren’t affected by it, why are you in the meeting? Application testers should represent the users who will eventually work with the application. Organizations have used all sorts of carrots to garner participation by people who might not feel they’re qualified to test software—everything from contests to see who can find the most legitimate bugs in an application, to paid time off for a job well done. I knew one organization that actually made up T-shirts in different colors for team members who provided valuable input; each color represented a new level of participation. You can bet that participants wore their T-shirts with pride because management made such a big deal about them. Be creative and have fun, but most importantly, get people involved!
A lack of communication at some level kills most development efforts. The failure to communicate may be one of misunderstanding or a lack of involvement, but good communication is an important part of the application development process. Developers must communicate with each other as well as with the various stakeholders affected by that application.
When one development team works with another development team in the same organization, both teams must be willing to give up some autonomy for the common good. The moment you begin to see a failure to communicate, you must stop the development effort and rebuild the communications. Any further effort at that point is doomed to failure. Once communication is re-established, the development effort can resume with at least a chance of success.