Before I left college the only experience I had in software development was as a one-man team. I did all the design and back-end development. There wasn’t a conflict of interest between designer and programmer, because they were both one person! As I left college and got into the “real world” I found that it was impossible to do large-scale software development by oneself. All of the sudden there were information architects, program managers, user interface experts, database administrators, technical writers, and on and on.

I came to realize the value of specializing in one field. For instance, it would be counter-productive to mandate a DBA to learn Photoshop inside and out, and likewise it would be counter-productive to have the UI person learn how to know how to write every variation of database indexes. But I also saw the lack of knowledge that each had even of what the other team member’s responsibilities were that led to inefficient meetings, miscommunication between clients (especially in terms of requirements gathering), and overall it lead to a “that’s not my job” mentality that hurt the overall productivity of the team.

The Thesis

I believe we need address the lack of communication between the team members by increasing collaboration and at least a general knowledge of what the other is doing. If the programmer knows that the UI person is very concerned with Web standards then they can address that while he designs (among many other examples). All members of the team address the same client with the same requirements, and with knowledge of the various aspects of the SDLC the client can receive the maximum amount of value for their investment.

The article is broken up into examining the role and duties of the project manager and the developers. Both have unique responsibilities in order to ensure that the efficiency of the team is what it can be.

The Responsibility of the Project Manager

The responsibility of making this work falls on all members of the team, but the project manager (project lead, technical lead, etc.) is the one that has the authority to delegate who will work with who and for how long. There should also be a strong impetus for this person to embrace this ideology, because when conflicts arise between developers or between developers and clients the project manager is the one usually responsible for resolving the conflict.

By delegating developers to have a working knowledge of what the other members are doing through the software development and maintenance cycle then all members are able to offer constructive criticism to one another and help in a time of need. It is a great asset in the toolbox of delivering quality software.

Reduce Developer “Possession” of Code
I was sitting in a meeting, and when a customer bug request came up in a certain module then we automatically pointed to that one person who designed the module. The mentality behind it keeps other people on the team from double-checking the code and able to help each other of bug fixing and future development. Kent Beck, the popular proponent of eXtreme Programming (XP) (which I neither endorse nor discourage) says the following on “collective ownership.”

“One of the effects of collective ownership is that complex code does not live very long. Because everyone is used to looking all over the system, such code will be found sooner rather than later. And when it is found, someone will try and simplify it. […] Collective ownership also tends to spread knowledge of the system around the team.” (Kent Beck. Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series). New York: Addison-Wesley Professional, 2004.)

Regardless of whether one uses XP or another SDLC, the concepts introduced are a good starting point to increase the amount of communication between team members, increase productivity, reduce errors, and deliver higher levels of customer satisfaction.

Facilitate Team Briefings
We all love to talk about what we’re passionate about; so why not use that to the advantage of your team? I work on a team where the project lead encouraged us to give a briefing on a new technology or certain aspect of their job that would benefit other members of our team. Let’s use an example.

The user interface designer is constantly frustrated why the DBA and developers just don’t “get” web standards. It leads to conflict, because the developer is solely concerned about the function and not the form (in an extreme example). Well, why not let that designer brief the team on the value of web standards? It would also be helpful for that individual to outline best practices so the application has both maximum form and function. Often miscommunication happens over very small issues, and by taking the time to clearly outline a concept then the problem often goes away.

In fact, recently I gave a briefing to my development team introducing CSS and CSS best practices. Months of frustration on my part was alleviated as many members of the team started to see the business value of separating presentation from structure. We are now converting our old table layout to a CSS-driven layout.

Managing Many Egos
Let’s face it-designers and programmers have egos, and not just small egos but large egos. Everyone has their own philosophy on how development should be done; this is normally a good thing that brings variety and many perspectives, but sometimes it can also be a hindrance when trying to empathetically communicate with team members.

How many technical meetings have we all been in that seemed to go on and on and seemingly accomplish nothing? It seems like we spend most of the time debating philosophically on the best route which is perpetuated by our own individual ideologies. This can, and should be, alleviated by realizing that what’s best for the application isn’t always how we feel it should be.

The project manager has the added responsibility of ensuring that these debates don’t get out of hand by effectively managing the conversation and ensuring that every side is heard. Ultimately, every business decision that is made must be made by some superior who weighs the options and chooses the best. A manager that is open yet firm in making decision does wonders for moving development along.

The Role of the Developers

The project manager can do quite a bit to ensure to ensure that the team works in an optimized state, but ultimately it comes to the people that comprise the team-the developers. I want to give a few suggestions for the developers to ensure that cohesiveness is improved.

Everyone Should Test Everything
A great way to get team members to get involved with the entire project is to not relegate testing to individual projects or a singular tester. By involving all members of the team in testing helps ensure that the quality of the application will continue to increase. I am continually amazed at how members of my development team don’t even know how to use many aspects of the very application they develop. It is often the result of the “possession” of code problem address above.

Improved Knowledge Management
A good development team should be the most experienced and concerned about knowledge management. As the application matures then it becomes more and more necessary to ensure that correct and complete documentation is retained (although don’t wait to start). The great knowledge management challenge of capturing tacit (un-written) knowledge is critical to address when you’re in a development team. As developers come and go the need to be less reliant on one or two developers is extremely important. You should, at least in theory, have enough documentation to move developers around and if necessary to replace.

Fostering Mutual Respect
Aretha Franklin had the idea when she said: “All I’m askin’ / Is for a little respect”. We all love to know that we are respected by our peers, but it only comes about when we extend it to others. That whole Golden Rule idea is very applicable in this situation. When developers create an atmosphere where we respect one another and each other’s contributions then more efficient communication is likely to take place.

In Summary

There are many ways to engage the entire development team, and the responsibility lies within the managers and the developers. It is truly a trial and error effort, but if you and your team seek to improve in the areas above then you are more likely to deliver a quality product to your customers and improve professional satisfaction.