This chapter is from the book
This chapter is from the book
This chapter is from the book
3.4 Teams as Dynamic Nonlinear Systems
Development teams are made up of interacting individuals with different perspectives who generally do what needs to be done to complete a project. There are designers and testers, people who understand the application technology, and experts in software technology. Each is important, with unique experience, perspective, and priorities; each has a role to play. Throughout the project they need to interact, to communicate, to raise and address issues. As the project proceeds, the nature of the interactions changes. Each individual's interactions combine to become the team behavior. The theory of dynamic systems applies to this collective behavior of a team performing a development project.
Individuals typically fill one or more roles on a development team.
The project manager, or lead, develops and maintains the project plan, including cost and budget; prioritizes and schedules the content; staffs the project; and provides day-to-day leadership.
The project architect looks after the overall design and associated quality issues. Responsibilities include maintaining the integrity of the UML views, especially the top-level logical decomposition, and the problem report database. Brooks [Brooks, 1995] and others (e.g., [Booch, 1995]) consider the architect a key team member.
The business modeler models the business process that the system under development is intended to support.
The project requirements analyst analyzes the business model and other user input to develop the requirements database, including use cases and supplemental requirements.
The developer designs, implements, and tests individual object classes.
The integrator or configuration management staff defines the project code library structure, instantiates the configuration management environment, designs and implements the method of compiling and integrating the code (the "make" files), and creates the builds for testing and delivery.
The tester develops test plans, carries out system and component testing, and generates test and problem reports.
The documentation writer creates the help file and the content of the user guide.
Large projects require partitioning into several development teams, with each team responsible for some number of logical subsystems. With the exception of the documentation writer, each role should be instantiated within each team and at the project level. For example, there should be a project architect and a team architect on each team. The project architect looks after the overall system design; a team architect looks after the design of the assigned subsystems. All of the architects should form a joint design team. This sort of structure enables the communications necessary to achieve a coherent design. The same rationale applies to the test staff and the project team managers.
The person in each role has primary responsibility for one or more development items. However, they cannot work in isolation; they must communicate with other team members to be effective.
3.4.1 Order and Team Communications
One distinguishing characteristic of a development project, as a dynamic system, is that the entities are people, neither machines nor chemical molecules. The emotions and motivations of the team members are among the conditions and variables that interact to govern their behavior. Applying leadership, you affect these variables and steer the project.
Several scientists have considered models of how systems of interacting discrete entities evolve [Kauffman, 1996; Lewin and Regine, 2000]. They have found that the nature of the system is determined by communications among the entities:
If communications are too restricted, the system will be in a stable equilibrium.
If communications among the entities are excessive, the system becomes chaotic.
A middle range is optimal. With just enough communications, the system is at the edge of chaos and evolves stable, manageable structures.
The following observations about communications are directly applicable to project teams, which consist of independent, interacting entities.
When a team is too restricted in its communications, it does not have the means to adjust to the challenges of a development project. This can happen if the manager insists on being in all of the communication paths.
If communications are unstructured, the project is likely to become chaotic. This can happen if the manager is uninvolved and the team must organize itself.
One of the critical management tasks is to develop an organization that enables and promotes the right amount of communications.
This observation reinforces the wisdom of Brooks [Brooks, 1995] and others:
TIP
The key to leading successful projects is the right amount of communications.
This idea is entirely consistent with the software development economics model discussed in Chapter 4.
This new common sense provides a final insight: The global behavior of a nonlinear interacting system emerges from the totality of local interactions. It follows that you cannot mandate how your team will behave, but you can influence its behavior by the nature of your communications with team members. Think of this kind of communications as constructive involvement. Being a part of the team allows you to provide the necessary steering to keep the team focused on delivering the right product and to influence overall team performance.
Chapter 6 discusses some mechanisms for enabling the correct amount of communications and participating constructively in team efforts.