The Cons of Current Methods

Let's look at an example of communicating the old way, using the different roles from MSF for Agile Software Development. Obviously not all teams will do things exactly as described, but the roles as described are valid enough to prove the point.

Let's imagine project development the old way: The business analyst defines the project vision and requirements using Microsoft Word; then he passes this document off to the project manager. The project manager begins to create a Microsoft Project plan, breaking the requirements into tasks for the developers to execute. While doing this, the business analyst discovers two more requirements. Instead of updating his Word document, he just e-mails the new requirements to the project manager included in his project plan. Of course, the e-mail server is offline at that time, so the project manager never receives it.

Meanwhile, the project manager has printed out the project plan for each developer, and given each a copy, showing them the work they are to do. The next day, however, one of the developers leaves the company. The project manager goes back to his project plan, and begins to readjust everyone's schedule. With the schedule readjusted, he e-mails the new project plan to everyone, with their new duties.

However, one of the developers, whose duties have changed in the new project plan, doesn't check his e-mail. Instead, he continues to work from the original plan that was printed out, and begins to duplicate work being done by another developer. As well, the business analyst discovers another requirement, and e-mails it to the project manager. Because it seems to be a simple thing, the Project Manager simply forwards the e-mail to a developer, and does not add it to the project plan.

At this point, you have out-of-date requirements and project plans, developers duplicating code, and nothing that ties any code development back to specific requirements. The project seems to be spiraling out of control - all because of the lack of good communication between different members of the team.

The following are all good technologies to use, and they have their place. However, they each have some weaknesses, which take some effort to overcome, especially if you don't have a central way of tracking your projects, such as Team Foundation Server.

E-mail

Pretty much everyone lives in their e-mail application. For many, that application is Microsoft Outlook. And, e-mail itself can generally be a very useful tool. You can easily pop off e-mails to different team members, asking for updates or answering questions. However, e-mail can also lead to problems. Response times with e-mails are a major factor. You may e-mail someone about a critical feature, and they don't respond for several days. What are they doing? Are they working on the feature? Is there something else even more pressing that is taking their attention?

As well, normally your e-mail client does not tie into your development environment. You can e-mail a new requirement or bug to the project manager, but the project manager still has to enter that information into whatever they are using to track project issues. Wouldn't it be nice if you could just open a new trouble ticket from your e-mail client, since you are in it all day anyway?

Many users use Microsoft Outlook to organize their task lists of what they need to work on that day. Again, they have to take the tasks they are working on, and manually add them to Outlook to track them there. Wouldn't it be nice if you could quickly and easily view all your tasks for a development project, without having to cut and paste them from your tracking system?

Telephone

The telephone is great for getting the answer to a quick or an in-depth question. The ability to easily talk to another team member, regardless of location, is a great asset. The telephone allows you to overcome the impersonality and incompleteness of e-mail and instant messaging, enabling you to quickly get an answer to a question or resolve an issue.

There are some drawbacks to relying on the telephone though. For multinational teams, language might be a barrier. However, the biggest drawback is its convenience. It's easy to call someone up to get the answer to a question. Then, when you get off the phone, you go "yep, I'll remember what they said." So, you don't write it down in a central location where others can also find the answer to that question. And so, the same or similar question get asked again and again. Not very efficient, is it?

File Shares

Every developer has done this at some point and time. They have copied their code onto a public file share, accessible by others, so other developers can look at their code. Every project manager at some point has copied his Excel spreadsheet or Microsoft Project file onto a file share, where it can be accessed by other team members. This is a quick and easy way to share project files with other team members, but it can ultimately lead to a lot of heartache.

If the file share is not secure, you are opening all your sensitive project data up to malicious users. And if you don't have the permissions set correctly on the share, other team members could overwrite your vital project data with old information, or even delete it accidentally. There is no tracking of previous versions of files either. It's just a bomb waiting to go off.

So far, you have looked at the negatives of how teams currently communicate - or don't communicate, as the case may be. In most cases, individual role members of a team are isolated from each other by the tools they use. Business analysts use Microsoft Word or Excel, developers use Visual Studio, project managers use Microsoft Project, just to name a few. Moreover, there are all the other tools out there for use by developers and testers in their every day environment. Again, many of these tools do not play nice with each other.