Organizational Options
Larry Constantine describes four organizational paradigms that characterize very different cultures [Constantine, 1993]. Each type of organization will respond differently to attempts to change the way work is done. To launch a software process improvement or culture change effort, first understand which model your organization is most like. Then select the approach most likely to be successful for inducing change in your climate. These are the paradigms Constantine identifies (see Fig. 1.2):
- Closed: A traditional hierarchy of authority, with decisions usually imposed by those above you on the organization chart; such organizations are oriented toward stability and continuity.
- Open: Integrates stability with innovation, and individual with collective interests; adaptive collaboration, flexibility, and consensus-building are typical characteristics; change likely will succeed, provided that the team members participate in the decision-making, planning, and implementation.
- Random: Characterized by innovative individuals who go their own ways; change proceeds through creative autonomy; team members can be creative and energetic, but definitely are individuals.
Synchronous: Features harmonious alignment of individuals with a shared vision of goals and methods, where rocking the boat is frowned on; the shared culture focuses on the status quo, with little conflict or chaos; groups operate efficiently through tacit agreement on roles and responsibilities.
Figure 1.2: Characteristics of Constantine’s four organizational paradigms.
It is not so much that any one of these organizational cultures is superior to the rest but that different change techniques are likely to succeed in the different environments. Also, the different cultures demand different leadership styles [Constantine, 1995].
Perhaps the best fusion of attributes selected from among these paradigms is found in the structured open team. Table 1.1 lists some of the special characteristics of a structured open team [Constantine, 1993]. The culture embodied in such a team is more likely to enable consistent software engineering excellence than is the culture in any of the four basic organizational types.
Table 1.1. Characteristics of a Structured Open Team.
|
In a workshop Constantine presented on team composition and roles, he did not identify the presence of a leader as one of the distinguishing features of a team. While teams in some cultures can be successful without a leader, I believe an insightful, visionary, decisive, and sensitive leader can have an enormous positive impact on the effectiveness and group dynamics of most teams. Conversely, a team without such a leader might well turn into an unfocused group of individuals doing their own work as well as they can, with interpersonal problems going unresolved, resources applied inefficiently and to the wrong efforts, and results determined solely by individual capabilities and work ethics.
If you can find a group of talented individuals who interact effectively on a peer-to-peer basis in a self-managed team, that’s terrific. Even on such a team, one person often emerges naturally as a de facto leader. Sometimes, multiple leaders emerge in various domains, with different individuals leading technical, organizational, administrative, and communication aspects of the work. A dynamic leader can be the dominant factor in getting a struggling group to jell and focus on a culture of taking the right actions at the right times for the right reasons.
Other models of culture in software organizations have also been proposed. In The Olduvai Imperative, Peter DeGrace and Leslie Hulet Stahl describe two opposing cultural views of software engineering, which they term “Roman” and “Greek” [DeGrace, 1993]. The Roman view reflects the characteristics of many larger, older development organizations. Greek thinking is more likely to be found in smaller, more dynamic software shops. Table 1.2 summarizes some of the attributes of these two cultural modes. Driving change in these two types of organizations will require very different approaches.
Table 1.2. Aspects of “Roman” versus “Greek” Software Engineering Cultures.
The Roman Way |
The Greek Way |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|