| началоstart ~ софтуерът-и-азsoftware-and-i ~ биография/cvcv/resume ~ библиотекаlibrary ~ снимкиphotos ~ детскиkids' ~ | български/.bg english |
If you're not ready to deal courageously with your shortcomings and to embrace organizational change, then you need to get to a space where there is enough mutual trust and respect to lay a foundation for introspection and dialogue. Without trust and respect, there cannot be deep enough communication to get beyond discussion about process (which often reduces to blaming the role or person responsible for a given step of the process) to discussion about structure and ultimately about principles. Structure is about relationship. Principles, which generate these structures and relationships, relate directly to the organizational value propositions and what they portend for trust between roles and individuals. See BeyondProcessToStructureAndValues.
To increase trust and respect means to engage people who are not currently in dialogue; to engage them, you need to persuade them to become involved in something they currently aren't involved in. Block [BibRef-Block1983] defines politics as the attempt to have influence over that which one cannot control directly. So this problem is fundamentally political in nature.
There are two major attacks on this problem. The first attack would have your organization go through team-building exercises, would suggest changes in reward mechanisms to encourage risk-taking, or might suggest a change in management. The second approach assumes that such a core exists somewhere within the structure of the larger organization, and uses it as the target for the patterns, with hope that the health can spread to neighboring organizations.
Yet before any positive change can happen, the organization must be ready to change. In our studies, we have seen organizations in various states of readiness for change. Let's explore the most common conditions that prime an organization for change.
In some cases, such as ParcPlace, the problems are already apparent. But other organizations need prodding to face up to their problems. The TeamBuilding exercises help people come face to face with their problems. In effect, the TeamBuilding exercises create a crisis in the organization. The dissonance of a crisis is often a prerequisite for large scale cultural change. In Virginia Satir's model of organizational change, such a stimulus is called a foreign element [BibRef-Satir1991]. It takes a foreign element to get an organization off of top dead-center.
One organization we studied was mired in cumbersome processes and overly focused on management. It was clear that most of the troops chafed under their development processes, but the manager roles did not see the problem. The team building exercise made the managers see things as the developers saw them; it removed a blindness to a reality they couldn't see. This resulted in serious introspection among the managers. It wasn't clear whether they changed their organization, but it did provide a golden opportunity to do so.
While we don't advocate looking for trouble, dissonances that present themselves may lead to opportunities for improvement. Dissonances that are vague, such as feelings that something somewhere isn't right, invite introspection exercises to help sharpen the focus of pattern application.
Sometimes ill feelings can arise across the scope of an entire group or team, and the dynamics can often be laid at the feet of first- and second-level management. If a team as a whole or the team's manager feel threatened, the team is in danger of succumbing to two near-term countermeasures that often go hand in hand. The first is: work harder. Hard work, overtime, and shortened schedules are a common reaction to a wide spectrum of threats. The second is: hunker down. A team will close in on itself in the interest of completely shutting off detractions that could sap its time and energy or in any way detract from a focused effort to maintain control. It is an over-application of the pattern FireWalls. This can put the team at odds with influences that it should be heeding but which it feels it can resist. It can become a spiral that leads to increased desperation, harder work, and more overtime. These are the dynamics of burnout.
An organization that is burning out can't learn. It doesn't take the time to learn; all the time is focused on the deliverable. It may make stupid mistakes for failing to step back and see the big picture. This is why patterns like CompletionHeadroom and RecommitmentMeeting are crucial to a healthy organization. They keep the organization open to other individuals and teams--both teams they depend on, and teams that depend on them.
A group in burnout often tries to take control of everything it can because its members need the comfort of being in control. It may overstep its domain of authority and claim ownership for parts of the system outside its usual domain. A dysfunctional services group may rewrite parts of the operating system because it feels it can't trust the operating system people to do it right or to do it fast enough; in these scenarios, no one wins.
A worrisome sociological configuration arises in cases of extreme burnout. One strong team member--usually, but not always, a manager or lead technical person--takes charge, usually by creating a culture of fear, intimidation, co-option, or coercion. The resulting configuration, fed by the controlling individual, discourages social discourse, openness, and interactions outside the group. The group turns inward for all of its needs. In the most extreme cases of burnout where people are now spending much of their lives at the office, the team-centeredness extends beyond professional relationships to personal relationships. People start deriving their personal identity from work and from the team. Work relationships displace family relationships. The organization becomes ingrown, and incest becomes a good metaphor for what happens to the organizational family. The health of the organization and its individuals deteriorate, and there often is no turning back. Family and personal lives suffer. Eric Fogelin, a developer on the first release of Windows NT, had this experience [BibRef-Zachary1994]:
There is a small body of fascinating literature on this phenomenon to which we refer the interested reader; in particular, see the analyses by Bill White [BibRef-White1997], [BibRef-White1986]. You've probably heard the term: "get a life." People working in healthy organizations have "a life." They have outside interests, and their identity doesn't draw solely from work. A healthy work environment--one that can sustain its employees, learn, and grow--gives people the time and freedom for this individuation.
Ask a software professional about burnout, and crisis management or "death march" projects often come to mind. Some projects are poorly managed, particularly with respect to matched expectations between the customer and provider, and that can lead to obvious burnout.
However, some organizations manage by crisis. It is exactly this mentality that Deming railed against: to drive fear from an organization, to take the power of crisis away. Some popular methods today, such as Extreme Programming, offer this fear of fear as one of their prime drivers. But if one looks deeper one can find a deeper form of crisis management.
A protracted crisis mentality creates burnout, even in the absence of a real crisis. For example, daily status meetings are a hallmark of organizations in crisis. However, if the organization adopts a policy of daily status meetings, it perpetuates the crisis mode, or even creates a crisis mode. This can incent people to work harder. Even when not at work, the people will have work on their mind so they can look good at the morning status meeting. Other aspects of XP--such as the ability never to work alone, but to always have your thought processes open to a pair programmer--help sustain the crisis mentality.
Our studies have shown that crises strengthen management roles. In crises, managers tend to move toward the center of the organization, displacing the domain expert roles that carry the organization through everyday business. (You can see a social network diagram depiction of this phenomenon in the section StabilityAndCrisisManagement, below).
A crisis is almost always a surprise: an unforeseen glitch in the stability of the organization. What makes a crisis a crisis is that it upsets stability, and that it does so precipitously. (We sometimes talk of the "software development crisis," but something that has gone on for 30 years can hardly be called a crisis!)
In the same sense that you want to build a new organization on the stable core inside the existing organization, you want to hold the environment stable while you are making change. You don't want constantly to be changing the foundations. If the environment is noisy, and if the organization exhibits arbitrary behaviors, then you can never know whether a given change resulted in an improvement or made things worse, or neither! This is a fundamental principle of organizational change; it is one of the deepest principles of Deming's approaches to organization management [BibRef-Deming1986] and one finds it at the foundations of ISO process improvement methods.
The pattern approach to organizational improvement is attentive to the stable parts of an organization and attempts to detach itself from noisy, day-to-day variations. Part of this stability comes from attentiveness to the deep structure that ties to values and relationships; these tend to change less frequently than practices, policies, and processes. Part of this stability comes from role normalization.
Crises can and will arise, and some of the patterns (e.g., SacrificeOnePerson, DayCare) specifically address contexts with a crisis component. However, these crises are relatively small relative to the overall organizational structure and to the goals of the enterprise. Most of the patterns instead strive to head off crises; most of the scheduling patterns (e.g., CompletionHeadroom) are of this nature as are some of the structural patterns (FireWalls, EngageCustomers).
Software development, like mountain climbing, is an inherently risky undertaking. Yet there are two types of risks: there is risk that you won't reach the summit, or that your product is a flop in the marketplace. These are risks we must take; in fact, we not only take them, we enjoy these risks! We view them as opportunities rather than risks. On the other hand, though, there are risks that the whole undertaking will go to ground because we didn't plan for the weather, or more significantly, the team doesn't function well in the face of unforeseen difficulty (see, for example, [BibRef-Krakauer1997]). These are the true risks we must avoid.
There is no pattern--or pattern language--for risk management. Risk averseness is an emergent property of healthy organizations. As in Alexander there are no patterns for "safe house", safety is an emergent property of houses built around concepts of appropriately joined spaces that draw on human context. We have provided this one section on Crisis Management in the book to tie together this popular concern and to draw out the principles we believe address the concern. Most of the solutions to so-called crisis management are distributed through the patterns:
There are some things to be aware of in crisis situations.
Last, crisis can be a good thing. We don't believe that organizations should seek crises, but neither should they be so risk-averse that crises create fear. Crises create opportunities for learning; a postmortem of a crisis can sow seeds of great organizational learning.
Or not. Read on.
Bertrand Meyer teaches a rule of object-oriented design called the open/closed principle [BibRef-Meyer2000]. It combines two ideas:
Team evolution is the same way. If a team does not have final say over its membership (SelfSelectingTeam), focus (TeamPerTask), and direction, resentment will build and the team will lose its sense of identity. Teams of course must sometimes negotiate with other individuals and organizations and sometimes must compromise, but as a rule teams should conduct their own business.
This is why ConwaysLaw is such a key pattern in two of the pattern languages in this book. Teams and groups are built around domains of specialization and expertise. And teams are staffed with the people who can serve that discipline (DomainExpertiseInRoles). Meddling from the outside only detracts from the team's focus.
So a team enjoys some autonomy in reaching a healthy steady state. But what about dealing with growth and dysfunction? And how about dealing with change? The outside world is always changing: the market, the technology, everything! The team must be open to external communication.
We can talk about this openness at two levels. As the software evolves, the architecture inevitably evolves and the teams must align their software to track architectural creep. (Actually, each team's software causes the collective architectural creep, but from the perspective of any single team it appears as though it is the rest of the world that is changing things out from underneath them.) So though the team is closed to meddling with the invariants related to its core competencies, it must be open to changes in interactions with other parts of the system. Such architectural changes may change the organization's communication network.
For example, let's say that you're working on a telephone switching system and your company is incorporating a new integrated circuit to accommodate market demand for a new protocol. The expertise about that chip resides in the heads of some people somewhere, and if you are going to be developing software that interfaces with that chip you're going to be talking to those people. Conway runs rampant in dynamic projects.
That's a simple example based on software change. Organizational change can be much more subtle. Technological change (like adding the new integrated circuit) doesn't hit people very deep with respect to their averseness to change. Organizational change, on the other hand, can be a strong threat. It can make people feel that their power base is threatened if they are made to report to a new manager. It can make people feel their job security is challenged if a new person is hired into the same area of specialty.
Sometimes the best laid plans of mice and men go astray. In complex systems such as human organizations, cause and effect can be far from each other in time and space [BibRef-Senge1990, 63]:
Introducing an empowerment program is supposed to increase the energy level, to remove constraints that will free people to do what the enterprise needs to have done, and to give people a sense of control over their destiny.
Think about this from the perspective of the open-closed principle. Empowerment increases the degree of closedness of a team. Giving a team autonomy might cause the team to weaken its interactions with important stakeholders and with sources of information and constraints that are important to the successful operation of the team. Empowerment might be particularly effective in diluting information exchanges with roles that exercise control in general, and with management in particular. In theory, this might create problems with respect to the open closed principle. Unfortunately, that is exactly what we find in practice. We have seen this in some of our organizational studies, but there is also research from Rutgers that concludes that this is a general outcome of empowerment programs [BibRef-Yates1995].
Empowerment is an attempt to achieve an effect (increasing individual leverage) by directly attacking its cause (the "distractions" of coupling and communication that "get in the way of work"). But this is not a system view; the solution cuts off the very nurturing that may have powered the team to its level of performance in the first place. Empowerment is a possible contributor to burnout.
We have also seen a lighter but almost equally deadly form of this phenomenon which we describe as schismogenesis. The term dates back to the work of Gregory Bateson [BibRef-Bateson1958] in 1936 in his work with tribes along the Sepik River in New Guinea. Symmetrical schismogenesis occurs when two factions each rise in power, or fear or distrust of each other, and form cliques or splinter groups that tend to focus inward rather than resolve issues in dialogue with each other. This is also a natural outgrowth of efforts to merge separate companies: the separate groups already exist with different values and cultures. The merger, with the spectre of job cuts, sows fear and distrust just at the time the organizations need to learn to work with each other.
Complementary schismogenesis occurs when a stronger side is compelled to actions by its fear of being taken down by a weaker side. We have seen this in organizations under the stress of an impending downsizing program, where the core members of the organization become disconnected from the support arms of the organization. It also occurs in mature organizations, where power structures have become entrenched. This is the main reason for the patterns ResponsibilitiesEngage and HallwayChatter, which came out of an earlier pattern named "Buffalo Mountain" that was designed in part to address schismogenesis. The pattern TheWaterCooler can also help reduce tensions between constituencies by creating a "place" for new social structures that are allowed to violate institutional structures. The HallwayChatter_ pattern gives an example of an organization exhibiting schismogenesis.
It may be obvious at this point, but such organizations are not candidates for the patterns in this book. To apply the patterns requires dialogue and interaction; that's the "open" part. It also requires focus and a healthy sense of team pride (see UnityOfPurpose). There is of course no black and white here. The balance between open and closed is subjective. It is also true that burnout is a spectrum: of course organizations put in long periods of hard work. But to go more than a month with consistent 60-hour weeks is a real danger sign. Even if the organization is not going into burnout, individual effectiveness and efficiency wears down very quickly after too long of a death march.
Many of the patterns in this book address this issue, keeping the organization vibrant and healthy so that it can adapt to change. A closed organization has difficulty changing effectively. Look at PublicCharacter, who helps information flow efficiently. Or at GateKeeper, who explicitly breaks down walls around the organization, and helps balance the FireWalls pattern. HallwayChatter_ reflects an informal social infrastructure of both technical and friendly exchanges in the workplace. Even DevelopingInPairs can be a useful pattern for the exchange of ideas and information across groups if the pairing is done across team and organizational boundaries. And of course it's important to keep in contact with the people who pay the bills through patterns like EngageCustomers.
As described above in HowThePatternsCameToUs, role playing is a staple of our research technique. We bring the organization together in one room where they role-play one of their processes: the design-coding process, or the testing process, or the acquisition process, or the analysis process, or the field support process, or whatever it is the organization believes needs attention.
One goal of the role-play is to put the team members into the psychological roles they play on a day-to-day basis. If one succeeds in doing this in a large group, it helps the group as a whole see itself in action and see the patterns of interaction that emerge. Reflecting on those patterns, those communication structures in the group, is the main foundation of organizational growth and renewal.
But the formal role-play can sometimes be the key to more powerful modes of introspection or to ways that are more suitable to the organization's culture or comfort zones. At Allianz, we did some initial role-play exercises with two of the development teams. Those exercises supported a bit more dialogue and interest in the groups on organizational issues but themselves did not cause major changes in ways of doing business. However, those initial studies led to follow-up work to explore the application of DevelopingInPairs and other ideas from Extreme Programming [BibRef-Beck1999] under the leadership of Thomas Tik of Allianz, Jim Coplien, and Laurie Williams of North Carolina State University. We decided to have an off-site meeting with the engineering teams, where we created an environment for open, constructive criticism of management and a lot of unstructured time. In addition, we spent time teaching them about DevelopingInPairs_. Those activities led to some management insights and realizations. Later, we were able to act on that experience to leverage change at the next higher level of management, and that broke a logjam that opened the floodgates of dialogue at the next level. Organizational improvement followed in its wake.
Similarly, at ParcPlace Systems [BibRef-Gabriel1996], we held a team role-play exercise. The vice-president of engineering, Richard Gabriel, had already started creating history time lines and having other forums that built on the team's frustration with its state and its desire to return to the environment of its glory days. The role-play was a watershed event to the extent that it underscored much of the dysfunction in the organization at that time and provided an external corroboration of the state of the organization. It also provided a forum where the team members could start thinking about patterns and talking about their dysfunction in terms of patterns. While the role-play exercise was only a fraction of the introspection, it was one of the main introspective events that involved the entire team, and offered foundations to support ongoing dialogue and organizational renewal. Yes, they even used some of the patterns in turning the organization around. But more important, they wrote their own organizational patterns and took charge of their destiny. This sense of ownership and taking charge, tied with the creation of a tangible body of patterns that they stood by, were perhaps the centerpiece of the organizational turnaround.
Techniques such as the organizational role-play can help develop the models and shared perspectives that can be seeds for the dialogue that strengthens a team. A retrospective [BibRef-Kerth2001] is a powerful team-building tool that yields both explicit and implicit benefits; the role-playing exercise described above is a form of retrospective. Most importantly, retrospectives help build a foundation for trust between the members of an organization. Seeing one's self in relationship to others helps people establish models of expected behaviors. These models either open communication paths or show where communication paths have broken down because of mistrust, environmental factors, temperament mismatches, and other factors. Team dialogue alone can identify environmental factors and some of the other factors, but it can actually strengthen the first and most important factor: trust. Using patterns such as those in this book can offer a rallying point for the team and can offer vocabulary for talking about the team's problems and potential solutions. But there are many other team-building techniques that can be equally effective.
In the case of both ParcPlace Systems and of Allianz, we found a solid core of people to start working with. This is almost always a preferred mode to doing team building for its own sake, because the structures are already in place to support the communication and dialogue necessary to reason about improving communication and dialogue!
In the case of ParcPlace Systems, the engineering group was drawn together by a common sense of disappointment and by a desire to have a feeling of control. From one perspective it wasn't an ideal organization for the application of organizational patterns. But on the other hand, desperation can drive out fear. One thing we did when we visited the organization for the role-playing exercise and initial round of evaluations was to leave them with the thought that they were indeed in very bad shape. It wasn't an exaggeration, but coming to grips with that fact perhaps gave the group courage to do things it otherwise wouldn't have done.
In the case of Allianz, the engineering group was one of several groups that had difficulty integrating their processes in the work environment. There was strong support for organizational work in second-level management and to some degree in third-level management, while first-level management (team leaders) were more focussed on technical solutions than organizational solutions. But the support for organizational work was stronger in engineering than in the other organizations. This concern for human issues was evident in the engineering work environment; a high degree of camaraderie and interworking could be found within the engineering team--and with their colleagues in the other teams--and their concerns about organizational health related more to the interactions between teams than to the dynamics within their own teams, as they had already reflected on those and had come to a point of satisfaction with their operation.
In both cases, the adoption of patterns in the small cohesive teams gave those teams tools for dealing with other organizations in the enterprise. This gave those teams a firmer foundation for congruent, productive relationships with the other organizations instead of the more contentious and sometimes combative (either openly or subversively) behaviors of the past. The congruence was a face-off of sorts: it provided a hard wall of integrity and well-reasoned behavior that was more difficult to subdue than in the past. That, in turn caused behavior changes and even doubts in the other organizations, and led to the eventual spread of the change culture to those organizations as well.
The key in both cases was to start with the healthiest team--in terms of its ability to introspect and learn--and to nurture it.
The answer is simple: pick a pattern to start with, and then apply the patterns one at a time. We will go into more detail in a few moments, but first a warning: Do not attempt to apply these patterns at once! Do not sit down with the pattern book in one hand, and your organizational plan in the other, and attempt to design your whole organization. These patterns must be applied in a piecemeal fashion. In fact, that is the only way an organization can change effectively; it must grow and mature organically.
There is a style of organizational design that believes in formalism, repeatability, and control. This school of organizational design is typified by ISO 9001 compliance programs as they are usually carried out. Perhaps Osterweil's (now quite out-of-vogue) Process Programming [BibRef-SuttonLernerOsterweil1997] is the epitome of this school of organizational design. Such approaches suggest that if we get everything right up front, all else will follow.
Unfortunately, it is impossible to foresee the complexities that beset even the healthiest organization. Human behavior is one of the most pernicious things to predict because it emerges from thousands of considerations and inputs, each weighted differently, that feed the decision processes behind organizational evolution. This makes it difficult to plan organizational structure. Changing economic conditions and markets, changes in the employment roll, in the law, and even the national mood can upset organizational design.
Some organizational structures change slowly and can be depended on as foundations for the evolution of an organizational design. These structures come not from an analysis of the future, but from an analysis of the past. Such structures can be formalized using techniques such as domain analysis and, in this case, one can make an analogy between domain analysis and patterns. Some of the patterns in this book are like that; more so those in the ProjectManagementPatternLanguage than those in other parts of the book.
But most of the time, successful organizational growth takes place in a piecemeal fashion, in real time. One of the pattern chapters is called PiecemealGrowthPatternLanguage, which contains patterns about how an organization grows and develops -- gradually. Note, however, that although you apply the patterns one at a time, they do not operate in isolation from one another. You must consider applying all patterns in a process of piecemeal growth.
In a piecemeal growth environment, the focus is on ongoing repair rather than on forecasting and anticipating. In fact, all design is in some respect an act of ongoing repair; we employ the feedback that comes to our senses from the emerging design to modulate the direction of design from that point on. So much the better that one is dealing with a live system and receiving its feedback than when working in the abstract with just "a design." Nature works the same way. Organizations, and their evolution, seem more to follow the laws of nature than the laws of modular design of design in any field with human-created artifacts. And nature works in the now, with feedback, employing repair.
The piecemeal growth philosophy comes from Alexander's vision of how patterns should be used, and pervades his work. The 6-step process below is derived from his yet unpublished work The Nature of Order. (Volume one has been published so far [BibRef-Alexander2003].) But piecemeal growth also surfaces frequently as a key management strategy. One of the main principles of organizational change in AT&T organizations in the 1980s was that one shouldn't try to change more than three things at once. Culture can change, but it loves stability.
More broadly, the pattern philosophy of piecemeal growth is a broadening of the popular notion (particularly during the late 1980s) of organizational learning. There are several excellent books on organizational learning; our favorite is "Becoming a Learning Organization: Beyond the Learning Curve," by Joop Swieringa and Andre Wierdsma [BibRef-SwieringaWierdsma1992]. There are strong parallels between the organizational learning field and patterns. For example, each believes in building on a small number of principles that generate rich emergent behavior; complex systems of rules don't work [BibRef-SwieringaWierdsma1992, 9].
A pattern-based piecemeal-growth repair process is robust for two major reasons. The first reason is that we don't do random things at random times. The patterns encode wisdom born of experience and follow sequences that have repeatedly worked in the past. Second, the patterns build structures which themselves offer a degree of resiliency under change. DomainExpertiseInRoles and FunctionOwnerAndComponentOwner are good examples of patterns that help an organization ride through common changes. If one organized around expertise related to a given product, the organizational structure would be sensitive to changes in the market. The market can be fickle and tends to change much more rapidly than the expertise associated with a given domain. FunctionOwnerAndComponentOwner_ honors the tradition of giving focus to the marketable item; after all, that's where the money is. At the same time it guards the long-term stable structure of the system, its underlying knowledge, and the organization that sustains it by also according ownership on the basis of components. DomainExpertiseInRoles_ helps the organization build foundations around core competencies rather than around current market (or management) fads. The organizational patterns encode that robustness and experience.
The ProjectManagementPatternLanguage_ can be an inspiration for principles and structures to get you started. It offers many long-term stable domain structures having to do with organizational structure, certainly for software development. Rough forms of these patterns will fall in place early in the formation of a new organization, and these patterns can be honed, fine-tuned and polished over months or maybe years to make them really shine. While DevelopmentEpisode can be an almost methodological construct, one that can be implemented almost overnight, patterns like WorkFlowsInward have more emergent results that come about over time. And even the seemingly simpler patterns like DevelopmentEpisode_ are cultural changes that will breed discomfort and take some getting used to. Each pattern is a small foreign element--an upsetting even--in its own right (see DissonancePrecedesResolution). Still, the ProjectManagementPatternLanguage_ is a good "starter set" for most organizations. But your mileage will vary, and you should defer to your instinct and insight.
That foundation in place, you can slowly make improvements by applying one, or maybe two, patterns at a time. Fundamental to the nature of patterns is that each can be applied in its own right without undue consideration of other patterns. Each pattern encapsulates a set of forces, or trade-offs (see WhatArePatternLanguages? above) that are as independent as possible from the forces in other patterns. Ideally, each can be applied in isolation. Ideally, there is no backtracking.
There are of course limits to this idealism. An organization is a system and a system view can be important to keep you from being blindsided. There is no formula or recipe for combining pattern application with insight; it is indeed your deeper insight that will tell you what the proper mix is. We as authors of this book trust you as shepherd of your organization to build on that insight. We provide some hints in the form of patterns, some insights on how the world tends to work well, and trust that those will serve as inspiration for you. This book is not a medicine cabinet. Patterns are not magic remedies to cure ills (more on this in OrganizationalPatternsAreInspirationRatherThanPrescription).
There is a rhythm to the application of patterns and people tend to underestimate the process that makes patterns work. That process is a process of piecemeal growth. One follows a sequence through the pattern language to increase wholeness, one pattern at a time. How, basically, does this work? Here is a synopsis of the process:
This process iterates after the pattern has had time to settle in and gain acceptance in the culture. That might take days; it might take months. Again, use your judgement.
Piecemeal growth is guided by sequences. A pattern language is a graph, and there are almost innumerable useful paths through it. There are two cues you can use to know which pattern to apply next. One is to look at the structure of the pattern language. The individual patterns tell about what patterns should come next as refinements and progressive steps, and the numerous figures of the pattern language graphs can also be a guide. The other guides that are useful are the sequences that other organizations have followed. The section on CaseStudies looks at the paths followed by several organizations on their rough road to success. They are stories. Stories can offer powerful insights into business choices, and we offer them to you for that reason. Read them through and look for things that hit home.
If you are familiar with Design Patterns in software architecture, you probably feel it is obvious when to apply a pattern: when a problem arises during design or implementation. When do you apply organizational patterns?
Remember that the system you are building is more that of a human organization than a software artifact. Change upsets organizations. Good change comes from a process of consensus, and it takes time and focus to develop consensus. Project retrospectives [BibRef-Kerth2001] are an opportune time to consider the new application of organizational patterns to the organization. Retrospectives are an opportunity to sit back and consider the organization as a whole, to find the pressure points of change that will give rise to the right kinds of emergent structure and behavior. Making changes during a consciously planned retrospective helps avoid making decisions in the heat of battle; it can help lead the team to changes that are more systemic and less reactionary in nature.
It is better to introduce organizational patterns between development cycles than in the middle of a cycle; this may coincide with a project delivery, or a change in technology, or perhaps an externally imposed change in organizational structure. Remember to make changes piecemeal and local.
The patterns in the chapter PeopleAndCodePatternLanguage might be applied as problems arise during development cycles; they are a hybrid between organizational patterns and software design patterns.
Each organization has its own patterns of effective communication and development. There are many different kinds of software development organizations: an organization that develops embedded software is likely to be quite different than one that develops in-house interactive tools. Each of these organizations is typified by its patterns.
The patterns in this book are neither universal individually, nor complete as a set. Each organizational can augment this book's patterns with their own patterns. Again, retrospectives provide an opportunity to capture good patterns and add them to the repertoire of good organizational practices.
See the story of the resurrection of the ParcPlace Systems team in [BibRef-Gabriel1996] for a story of a team that rebuilt itself around a pattern-writing effort.
One contemporary management fad is Goldratt's Critical Chain and Theory of Constraints [BibRef-Goldratt1999] which has some similarities to the process mentioned above, but which also has some stark differences. It is similar in that the focus at any given time is local, at a particular juncture of problems. But the pattern approach differs from Goldratt's approach in that there is a broader theory and structure guiding the process, a structure based not only on action/reaction but on encoded experience. Goldratt's techniques are more applicable to industrial and inventory processes that are less tainted by human emotion and dynamics. The pattern process is more suitable to organizations, which have a life of their own.
The greatest danger is to try to take control and to foresee exactly how patterns will work together, and to plan now in a way that anticipates how you will plan in six months' time. The world is more complex than that (see PeopleAreLessPredictableThanCode, below). An organization is an ever-evolving structure and organizational process improvement happens in the now. It pays to know history, and one shouldn't ignore the market and technological trends coming over the horizon, but to plan structure based on predicting human behavior is usually a mistake. This is a difficult thing for most managers: it requires a "letting go." Let go; think locally and act locally; trust your instinct and experience and the experience encoded in the sequences of the pattern language for the rest.
We mentioned above that organizational learning is a key property of effective organizations. Many of the patterns in this book concern effective communication in an organization. But communication can't have long-term impact unless there is group learning. That takes introspection. So the second main component of long-term viable teams is that they take time to introspect. That, of course, builds on good communication skills--and leads to UnityOfPurpose, which is one of the core properties of any effective team.
In this section we offer some brief, general rules for how to apply the patterns. Most of these have come from our experience of the past ten years, but others come from more general principles of patterns.
Most of us tend to be solution-oriented, and we naturally focus on the solutions in patterns. Yet the problem in a pattern is as important as the solution. The insights we gain about the problem--captured most often in the forces--can be just as helpful as the solution itself. In many cases, once we understand the problem thoroughly, the solution becomes clear.
As you read the patterns, look for problems that are similar to problems you now have or once had. But don't look for exact matches; they won't be there. You unleash the power in the patterns when you learn to adapt them to your own situation.
You can react to this fact in one of two ways. One way is to become angry and frustrated. You identify yourself with Dilbert, and begin to see your boss with pointy hair. "Why can't my company's upper management get a clue?"
There is a much better way, though. Instead of focusing on what you can't change, focus on the patterns that may apply to you. That set varies depending on your role. For example, you might find it useful to EngageQualityAssurance, or EngageCustomers. Perhaps you see yourself as a GateKeeper or a MatronRole. It may be worthwhile to strive to become so good at what we do that we eventually become a LegendRole.
In reality, we will react both these ways; we're human. The trick is to try to let go of the things we can't change. Or at least, they become filtering mechanisms when we consider taking a position in a new organization.
Note that every pattern has a context, which defines the boundaries of usefulness for that pattern. The context generally shows up at the top of the pattern, although some context is buried in the exposition of the problem. It is often difficult to separate the context and the problem. So you should read the context and problems with an eye to how they fit your particular organization. Note that the context of an organization changes over time. In particular, consider the following:
How large is your organization? In addition, how large and complex is the software you are working on? Several of these patterns apply best to large or small organizations.
How mature is your the organization? How long have people worked together? In mature organizations, the roles tend to be well understood. New organizations will be find the patterns of piecemeal growth of the organization more useful.
How mature is the software under development? This is different from the maturity of the organization. Mature software is more appropriate for HubSpokeAndRim, for example.
What is the culture of the organization? Sometimes, the organization's culture makes easier -- or harder -- to apply certain patterns.
There are indeed some patterns that are oriented toward individuals. The GateKeeper and MatronRole patterns, for example, describe single-person roles. Yet on closer examination, these roles are useful because of how they interact with others -- they cease to exist in isolation. Even a SoloVirtuoso is set up and managed by another person. Furthermore, and this is important, one of the keys to the power of patterns is that they establish a shared high-context vocabulary. That's a group thing.
So the question becomes not only how to disseminate knowledge of the patterns throughout the organization, but to also how to get people to use them. While nothing replaces the hard work of old-fashioned evangelism, we can offer a few specific suggestions.
One approach is to spread the word pseudo-subversively. Remember the description of Dick Gabriel leaving the patterns by the printer. You can also call out the patterns as you see them (or see their need) in your organization. People will become curious what ConwaysLaw is, and ask questions.
The most effective way we have seen to introduce these patterns is through the organizational studies. This not only provides a natural forum for introducing the patterns, but also exposes the need for them. We heartily recommend this experience.
This means that the results of applying organizational patterns are going to be inherently less predictable than applying object-oriented design patterns, for example. Imagine that your organization uses the ResponsibilitiesEngage pattern to help communication. But perhaps two people involved simply don't like each other? Personalities play a large part in organizations.
Organizational patterns have everything to do with the culture of the organization. Remember that applying these patterns requires, in many instances, changing the organization's culture. And because culture is deeply ingrained in organizations, this can be difficult and sometimes even painful.
Furthermore, it may be the case that great managers are the product of the great organizations they head as much as organizations are the product of their own talents. Kroeber (see PatternsInAnthropology) talks about the role of genius in culture. We think of Aristotle and Plato as exemplifying the greatness of Greek philosophy, and we think of them as having produced the philosophy ([BibRef-Kroeber1948], p. 145). But it is more likely that it is the culture that produced the philosophers, and that the philosophers articulated latent structures and concepts that the culture was primed to deliver. Aristotle and Plato are therefore remembered as great leaders, while the masses fade into collective obscurity.
Along similar lines of reasoning, Kroeber argues that great inventions such as the telescope, logarithms, the calculus, photography, the telephone, and exploration of the North Pole are products of culture and not the individuals usually associated with them. As evidence, he notes that each of these landmarks were achieved by at least two discoverers in the same era, and in almost all cases by individuals whose efforts were unknown to each other. The telescope was independently invented by Jansen, Lippershey, and Metius in 1608; logarithms, by Napier in 1614 and Burgi in 1620; the calculus, by Newton in 1671 and Leibnitz in 1676; photography by Daguerre and Niepce, and Talbot, in 1839; the telephone, by Bell and Gray, both in 1876. He lists about 20 other such coincidences known to history ([BibRef-Kroeber1948], p. 140).
By similar reasoning, great corporate managers--and even great line management supervisors--might be as much a product of the culture of their groups and corporations as the groups and corporations are products of their excellence. It is the patterns and the culture that lead an organization to excellence; the manager is the figurehead, mouthpiece, or icon that serves as the catalyst for the process towards excellence. (This same reasoning has sobering repercussions for common American interpretations of CompensateSuccess.)
Therefore, we feel that the best thing a manager can do is to lead a culture where it wants to go. It is true that this role wields a great deal of power in shaping the organization, and helping both individuals and the organization be effective. They can instill vision, they can sponsor the organization, and they can protect the organization from distractions. Although their contributions are indirect, they can be sizeable.
Many of our patterns are best applied by managers. This should come as no surprise, since the creation, care and feeding of organizations tends to be responsibilities of management. Even those applied by individual developers are usually influenced in some way by nearby manager roles.
Managers can use some of our patterns by themselves, or on themselves. For example, managers should protect developers from distractions by becoming FireWalls. They might be an advocate of the group and the project as a PatronRole. They can mold roles in their organization with OwnerPerDeliverable, TeamPerTask, and SizeTheOrganization. To a certain extent, they may be able to effectively CompensateSuccess, although some reward policies are dictated from stratospheric levels in the corporation.
Note that most of these activities can be viewed as keeping the organization in its own element, focused on what makes it good, rather than as activities that attempt to bring good or guidance to the organization. That is a guiding principle in these patterns. A corollary for managers is that a great manager probably cannot save a dysfunctional culture, but a poor manager might be able to keep an otherwise viable culture from thriving. We view these patterns as tools that help the manager help the organization to find its way, at the system level, partly by moving the manager away from practices that would stunt organizational growth.
Managers can nurture such critical roles as MatronRole, PublicCharacter, LegendRole, and WiseFool, which are outside their own sphere. They cannot force these or other patterns to be adopted by the team, but they might encourage it. Often, a team is primed to make a change and just needs a light to show the way to what then becomes obvious to the team, and one might argue that if major changes aren't already in the soul of the organization, they can't happen, anyhow. Dick Gabriel made copies of an early copy of the patterns in this book and left them by the printer. He encouraged the team to pick them up and read them, and they did so. Then they applied the patterns themselves; Dick didn't (and couldn't) force-feed the patterns to the group.
One key idea is that managers realize the limitations of their influence--exercise that influence when appropriate, but don't try to do more than is possible. We might remember the example of Oscar Hammerstein, collaborator with Richard Rodgers on many Broadway musicals. Once when a friend asked Hammerstein what it was like to work with Rodgers, he said, "I just hand him a lyric and jump out of the way." [BibRef-Linkletter1968] An internal AT&T management publication once featured a cartoon with a manager standing at the podium of an orchestra, clearly having been called to do something above his station and outside his experience, where we find he has opened the score to find the words: "Wave the baton until the music stops, and turn around and bow."
Детски нещаKids' things
* книжкиbooks
* творения:легоcreations:lego
БиблиотекаLibrary
* снимкиphotos
* хайкуhaiku
* водолет / e-foilwaterfly / e-foil
* обиКолелоroundaBike
* направи самdo it yourself
софтуерът-и-азsoftware-and-i
* био/cvcv
>> #OpenToWork <<
| '2008-2024 ~ началоstart ~ софтуерът-и-азsoftware-and-i ~ биография/cvcv/resume ~ библиотекаlibrary ~ снимкиphotos ~ детскиkids' ~ | az()svilendobrev _ com |