TeamworkYou hear plenty of talk about the importance of good team communication in many professions. From my writing background, I know that the relationship between writers and editors is extremely important (and complex in many ways).

When it works well, editors communicate their revisions and overall feedback to writers with clear and well considered arguments. Writers honor those edits in the spirit of their work, if not always to the letter, and discuss contentious issues directly with the editor.

At the end of the process, both sides should feel that value has been created, the piece is better than before, and the sum of writing and editing skills are reflected in a work of quality.

It’s really not all that different in the world of software development. In fact, software development is largely a team activity involving a complex chain of roles including business analysts, architects, developers, testers, team leads, and development managers.

Many people buy into the stereotype of the software developer as a loner, grinding out code in isolation, and rarely coming out into the light of day. While those developers exist (somewhere), most professional programmers today function in small to mid-sized teams, working on shared projects that require a high level of communication and peer review.

In this context, it’s easy to see how poor communication can wreck software projects, teams, and entire companies if allowed to take hold and fester. If this subject interests you, I encourage you to read Johanna Rothman’s short article titled When Teams Break Down, Business Loses.

She explains how competing teams within a data visualization company failed to agree on a uniform way of accessing the database. Roll on a few years and you’ve got a messy product with multiple library calls, unhappy customers who find the lack of standardization for data access unacceptable, and ultimately a failing company.

Johanna tells another war story about a large insurance company where different software teams simply could not agree on a standard iteration length for their agile process. A two month delay ensued from this basic failure to communicate with other teams and find a resolution, costing the company of over $2 million in revenue. Ouch!

So what am I trying to say here? With a rough economy, tight margins, and ever increasing competition in the world of software development — you overlook teamwork and communication across software teams at your own risk.

Add this post to: del.icio.us:Poor team communication = bad software digg:Poor team communication = bad software spurl:Poor team communication = bad software simpy:Poor team communication = bad software newsvine:Poor team communication = bad software blinklist:Poor team communication = bad software furl:Poor team communication = bad software reddit:Poor team communication = bad software Y!:Poor team communication = bad software google:Poor team communication = bad software technorati:Poor team communication = bad software stumbleupon:Poor team communication = bad software windowslive:Poor team communication = bad software