Effective software project teams are composed of people fulfilling a variety of roles. Each person takes on one or more roles; perhaps one person focuses on project management whereas another may be actively involved with both design and implementation of your system. Common project roles include:
- Analyst
- Architect
- Database administrator
- Designer
- Operations/support engineer
- Programmer
- Project manager
- Project sponsor
- Quality assurance engineer
- Requirements analyst
- Subject matter expert (user)
- Tester
How do you organize your team? Do you take a vertical approach where your team is made up of generalists, each of whom takes on a wide variety of roles? Do you take a horizontal approach where your team is composed of specialists, each of whom takes on one or two roles? Or do you take a hybrid approach and include both generalists and specialists on your team?
An important factor to consider is the nature of the people that you have available to you. If most people are generalists then you likely want to take a vertical approach, and likewise you would take a horizontal approach if most people are specialists. If you are in a position to bring in new staff, even if they are contractors, then you need to consider the priorities of both your project and your organization. This article describes the vertical, horizontal, and hybrid approaches to team organization and indicates their advantages and disadvantages. An important implication of this discussion is that your team organization and your approach to managing your project go hand-in-hand; any mismatch in approaches will likely lead to problems for your project.
A vertical team is composed of generalists. Use cases are assigned to individuals or small groups, who then proceed to implement the use case end to end.
- You have smooth end-to-end development on an individual use case basis.
- Developers gain a wider range of skills.
- Generalists are typically high-paid consultants who are difficult to find.
- Generalists typically do not have the specific technical expertise required to quickly solve detailed problems.
- Subject matter experts may have to work with several groups of developers, increasing their burden.
- All generalists are not created equal.
- Everyone is working to a common set of standards and guidelines.
- Good communication between developers is required to avoid common functionality being implemented by various teams.
- Common, and agreed to, architecture needs to be developed early in the project.
A horizontal team is composed of specialists. This team works on several use cases simultaneously, each member working on their own aspects of the use case.
- A higher quality of work is performed for each aspect (requirements, design, and so on) of the project.
- External groups, such as users and operations staff, interact with a small group of specialists who understand their exact needs.
- Specialists often do not appreciate the importance of other specialties, resulting in disconnects between various aspects of the project.
- Information required by "back-end" people may not be gathered by the "front-end" people.
- Project management is more difficult because of competing priorities, visions, and needs of specialists.
- Good communication is required between team members so that they understand where each person is coming from.
- Defined processes and quality gates that specialists must follow to promote effective hand-off to other specialists are required.
A hybrid team is made up of both generalists and specialists. The generalists stay with a use case throughout its development, supporting and working with specialists who work on portions of several use cases.
- You get the best of both worlds.
- External groups interact with a small group of experts.
- Specialists focus on what they are good at.
- Individual use cases are implemented consistently.
- You get the worst of both worlds.
- Generalists are still hard to obtain.
- Specialists still may not appreciate and work well with other specialists, although this should be tempered by the generalists.
- Project management is still difficult.
- Good team communication is required.
- Common architecture needs to be developed.
- Common processes, standards, and guidelines must be well defined.
Team morale as a project success factor
Most definitions of project success talk about how your project is on time, on budget, and meets the needs of its users. However, in a day and age where good software professionals are hard to find, let alone keep, this definition needs to be expanded to include the morale of the project team. Getting a software project out the door, only to lose key developers because you burned them out to do so, might meet your organization's short-term needs but it certainly doesn't do much for its long-term prospects for building an efficient software department. An important measure of project success is the morale of the team at the end of the project. It is important that, at the end of a project, the individuals on the project team feel that they all learned something from their experience, that they enjoyed working on the project, and that they want to stay with the organization to work on the next project.
- Process Patterns -- Building Large-Scale Systems Using Object Technology by Scott Ambler. New York: Cambridge University Press, 1998.
- The Unified Process Inception Phase by Scott W. Ambler and Larry L. Constantine. Gilroy, CA: R&D Books, 2000.
- The Unified Process Elaboration Phase by Scott W. Ambler and Larry L. Constantine. Gilroy, CA: R&D Books, 2000.
- Constantine on Peopleware by Larry L. Constantine. Englewood Cliffs, NJ: Yourdon Press, 1995.
- Peopleware: Productive Projects and Teams, 2nd Edition by Tom Demarco and Timothy Lister. Dorset House Publishing, 1999.
- "Organizational Patterns for Teams," Pattern Languages of Program Design 2, pp. 345-352, by Neil B. Harrison. Addison-Wesley Publishing Company, 1996.
Scott W. Ambler is President of Ronin International, a consulting firm specializing in object-oriented software process mentoring, architectural modeling, and Enterprise JavaBeans (EJB) development. He has authored or co-authored several books about object-oriented development, including the recently released The Object Primer 2nd Edition, which covers, in detail, the subjects summarized in this article. He can be reached at scott.ambler@ronin-intl.com and at his Web site at www.ambysoft.com.
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
