Software for Your Head: Core Protocols for Creating and Maintaining Shared Vision / Edition 1

Paperback (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $5.68
Usually ships in 1-2 business days
(Save 87%)
Other sellers (Paperback)
  • All (12) from $5.68   
  • New (6) from $32.49   
  • Used (6) from $5.68   

Overview

Most people have experienced--at least once in their lives--the incomparable thrill of being part of a great team effort. They can remember the unity of purpose they experienced, the powerful passion that inspired them, and the incredible results they achieved. People who have been on a great team can attest that the difference between being on a team with a shared vision and being on a team without one is the difference between joy and misery.

In 1996, Jim and Michele McCarthy, after successful careers leading software development teams at Microsoft and elsewhere, set out to discover a set of repeatable group behaviors that would always lead to the formation of a state of shared vision for any team. They hoped for a practical, communicable, and reliable process that could be used to create the best possible teams every time it was applied. They established a hands-on laboratory for the study and teaching of high-performance teamwork. In a controlled simulation environment, their principle research and teaching effort--the McCarthy Software Development BootCamp--challenged dozens of real-world, high-tech teams to produce and deliver a product. Teams were given a product development assignment, and instructed to form a team, envision the product, agree on how to make it, then design, build, and ship it on time. By repeating these simulations time after time, with the new teams building on the learning from previous teams, core practices emerged that were repeatedly successful. These were encoded as patterns and protocols.

Software for Your Head is the first publication of the most significant results of the authors' unprecedented five-year investigation into the dynamics of contemporary teams. The information in this book will provide a means for any team to create for itself a compelling state of shared vision.

0201604566B09042001

Read More Show Less

Editorial Reviews

From Barnes & Noble
The Barnes & Noble Review
Everyone talks about the importance of shared vision in achieving a common goal -- in software development, or elsewhere. Everyone talks about making teams work together better. Jim and Michele McCarthy actually offer a road map for achieving these lofty goals.

Some programmers' first reaction to Software for Your Head will be to recoil. On first hearing, this stuff sounds awfully touchy-feely. Consider: "Your degree of presence correlates with your degree of efficiency." Being present means being entirely present, emotions and all. And "emotional self-repression reduces both team efficiency and product quality." But if you think about it, you can see why it's true -- and the authors' "check in" concept offers a specific way to overcome it.

Software for Your Head addresses virtually every aspect of team success: making shared decisions and acting upon them; helping people become more receptive to each others' ideas; strengthening commitment to a project; overcoming "dysfunctional" and "neurotic" team behavior; and more. Along the way, McCarthys identify "supposed" project solutions that lead straight to perdition ("add more people") -- and then point to "real" solutions that might just work.

The McCarthys didn't just make this stuff up. They have extensive experience running large-scale software development projects; Jim McCarthy once led Microsoft's Visual C++ development team. Since then, they've led hundreds of software "boot camps," weeklong labs where developers team up to build working software. That's where these "patterns and protocols" evolved. Hey, you know there's got to be a better way than what you're doing now. This just might be it. (Bill Camarda)

Bill Camarda is a consultant, writer, and web/multimedia content developer with nearly 20 years' experience in helping technology companies deploy and market advanced software, computing, and networking products and services. He served for nearly ten years as vice president of a New Jersey–based marketing company, where he supervised a wide range of graphics and web design projects. His 15 books include Special Edition Using Word 2000 and Upgrading & Fixing Networks For Dummies®, Second Edition.

From The Critics
Jim and Michele McCarthy worked previously on successful software development teams at Microsoft and elsewhere before establishing a hands-on laboratory in 1996, for the study and teaching of teamwork. At their lab, teams of software developers come together for a five- day product development simulation, with the assignment of forming a team, envisioning a product, agreeing on how it would be made, and designing and building it. Over the past five years, through repetition of this simulation with new teams, the authors have been able to identify core structures and protocols which lead to successful teamwork. They present their findings here as a practical, communicable, and reliable process to guide others in their efforts at effective teamwork. Annotation c. Book News, Inc., Portland, OR (booknews.com)
Read More Show Less

Product Details

  • ISBN-13: 9780201604566
  • Publisher: Addison-Wesley
  • Publication date: 12/27/2001
  • Edition description: New Edition
  • Edition number: 1
  • Pages: 464
  • Product dimensions: 7.30 (w) x 9.00 (h) x 1.00 (d)

Meet the Author

Jim and Michele McCarthy founded McCarthy Technologies in 1996, after product development and program management positions at Microsoft, the Whitewater Group, Bell Laboratories, and elsewhere. Jim is the author of Dynamics of Software Development (Microsoft Press, 1995).

Jim and Michele McCarthy founded McCarthy Technologies in 1996, after product development and program management positions at Microsoft, the Whitewater Group, Bell Laboratories, and elsewhere. Jim is the author of Dynamics of Software Development (Microsoft Press, 1995).

0201604566AB12102001

Read More Show Less

Read an Excerpt

The Core V. 1.0 Background

We didn't create The Core. Instead, we watched it grow. We did, however, along with John Rae-Grant, create the set of initial conditions under which The Core protocols, or something very much like them, would almost certainly emerge. Over the years, we have maintained healthy conditions for Core evolution. Along the way, we also pruned the tree from growing into a few false directions. And we added resources: our own money, time, focus, and stamina. We protected it. Took notes. Tried it out. Passed it out.

A proper credit also has to include the hundreds of product developers and other students from around the world who contributed to The Core's development over the years. Crediting one person or segment of contributors exclusively would be inaccurate, however. The real story is both simpler and more complex.The emergence of The Core was in some measure a result of our experiences in 1994-95. We were working for a commercial software company, leading a development team of approximately 150 people. We used a homegrown aphorism to help us try new ideas:

Team = Software

That's the idea. Because of its many virtues, despite its deficits, and regardless of others who have had the same thought, this maxim became a bit of a mantra for us. During stressful times, when we were tempted to retreat from the overwhelming complexity of the software development tasks; when the confusion and disorientation were really getting to us; when schedules were slipping and goals receding and prospects were looking pretty grim indeed. Then, just when we needed it most, someone in our group would invariably come up with a new idea, would provide a fresh point of view based on "Team = Software." "I get it," he might say, and then rattle off some new application of "Team = Software" that could apply to our situation. Occasionally, these ideas were profound; more often they weren't. They were almost always useful, however.

The essence of the "Team = Software" philosophy is that the behavior of a team maps directly to the qualities of its product, and vice versa. If you want a product with certain characteristics, you must ensure that the team has those characteristics before the product's development.

We also realized that everyone has a product or provides a service. Everyone produces a concrete expression of his value system that carries that person's virtues and vices out into the world.

What was our leadership team making? We moved through the hierarchical levels in our organization and answered two pertinent questions at each interesting point: Who is the team here? And what is its product?

Let's call the team of frontline developers the Level I team. Level I makes the actual product. The managers of this team constitute the Level II team. Its product is the Level I team. When applying the "Team = Software" philosophy, the team on one level is the product of the team at the next higher level. If the Level II team sees an undesirable trait in the Level I team, it must be an expression of or reflection of Level II teamwork and the Level II team members. This pattern applies to teams at all levels, right up through the corporate ranks.

This idea may seem clever, obvious, fanciful, or just plain wrong-headed, but to us it was certainly helpful. Using this model, no one can hide from accountability. In our situation, even though we were bosses, we could not fault a team for lacking a virtue, unless and until we had personally demonstrated it. Nor could we expect any remedy that we weren't personally modeling. On the one hand, this realization was depressing, because there really was no escape: Responsibility inevitably migrated upward and weighed heavily from time to time on our well-paid, if under-exercised, shoulders. On the other hand, this realization offered an incredibly hopeful perspective as something more, something immediate, something completely within our control that was available to remedy any shortcomings of the team.

If we saw something screwed up somewhere or noticed some good fruit dying on the vine, we could immediately find and fix the problem. To inspire other team members to go get that fruit before it died, we would gather and visibly devour tantalizing fruit that had gone unpicked in our own neck of the woods.If we wanted any property to materialize on the Level I team, we would have to incorporate that property into our own behavior. This change in behavior was conceptually simple, but challenging to implement. In any case, keeping this basic framework in mind exposed many novel approaches to team problems. When we first applied this perspective, so many new possibilities opened up at such a rapid pace that we were unable to keep up with them. Although many little tests and a few big ones did yield the desired results, we saw so many new solutions to problems that had plagued us for years that we hardly knew where to begin. We quickly realized that we couldn't possibly conduct sufficient experiments to develop a full understanding of precisely how useful the formula was; to discover where it failed; or to see where the behavior it inspired might lead. We wanted to explore its dynamics and map its etiology in the systems we believed it governed—that is, check it out all the way.

Unfortunately, the experimental opportunities in a commercial software development effort are necessarily limited. A major obstacle is the simple passage of calendar time. A large commercial software project can take months or years. The possibilities we were seeing appeared so valuable, however, that even a few months seemed far too long for each cycle if we were to learn everything possible. With millions of dollars at stake on a single development effort, radical experimentation seemed risky. The number of variables with which we could tinker was low. Together, the sluggishness of "real-world" calendar time and the responsibilities of prudent business practices worked against the idea of implementing the sustained, radical, and rapid experimentation that we envisioned. Still, we thought big breakthroughs in team dynamics were possible—breakthroughs that could make collaboration simpler and more effective for any team.

To study this material in depth, we had to complete a development cycle in a much shorter time. Life itself was too short to go through enough development cycles. Even a very busy, unusually stable, and highly focused development manager could—if he stayed with the task for a long time—expect to oversee 10 to 20 projects in one professional lifetime. Many of these projects would use essentially the same teams, reducing the diversity of team sources that would enrich the manager's education and hasten experimental progress.

In early 1996, to accelerate the rate and breadth of our experiments, we went out on our own and established a laboratory devoted to the study and teaching of teamwork. The ultimate existence of The Core protocols became a virtual certainty when we decided how we would operate the new lab, which we named "Software Development BootCamp." The principal experiment conducted would be a recurrent product development simulation, lasting five days and nights with a new team each time. It would take place every month or so. The developers would complete four steps:

  1. Form a team.
  2. Envision a product.
  3. Agree on how it would be made.
  4. Design and build it.

At the end of the week, the teams would have to deliver their products on time, or stay longer to do so, or not, as they chose.

We knew that we could successfully conduct such a product development effort, even leading it personally, if needed. We had done just that for many years, earning our living in a variety of environments. We had sufficient information, tips, techniques, and useful practices to transmit high value to most students. We could teach them practices that could ensure the successful outcome of their own product development efforts, now or later, simulated or not.

We had already gained, organized, and articulated considerable knowledge from our experiences in leading or otherwise contributing to dozens of development efforts, most of which proved quite successful. This body of knowledge would serve as the starting point for the first BootCamp teams. Even if we learned nothing during BootCamp, we still would have plenty to offer.

BootCamp has allowed us to effectively compress a software development cycle into a five-day experience. In five days, students learn what would normally require a long development cycle. The intense BootCamp experience includes all of the failures and triumphs that occur with normal team formation; the creation of a team-shared vision; and the design, implementation, and delivery of a product. The days in each BootCamp are packed with accelerated team dynamics; what usually takes a year or more is created in a few long days and nights of exceptionally deep engagement.

The many new insights from BootCamp emerged at a vastly increased clip. The learning pace was accelerated by our experience of working intimately with some 60 different software development teams. We first helped to create the team, and then their products. We experienced complete development cycles with incredible frequency and velocity—one or two times per month at peak periods. Working with teams of every kind and composition, and working before and after BootCamp, we applied what we learned to our own teamwork.

One additional factor led to the creation of The Core protocols, and originated in our standard assignment to the students. Each team would have to build a product in one week. But what product would the BootCamp teams make?

At one level, BootCamp is conceptually simple: We assemble a group of software developers. Sometimes the students are members of a preexisting team. Sometimes they represent as many types of developers as possible: corporate employees, entrepreneurs, computer scientists, software testers, writers, editors, graphic artists, coders, managers, executives, program and project managers, and producers. Often, there will be nondevelopers in attendance: nurses, teachers, homebodies, consultants, and press members. We give each new team-in-waiting a single assignment:

Design, implement, and deliver a course that teaches you everything you need to know to ship great software on time, every time.

This assignment has remained unchanged since the first BootCamp. It seemed to us that it would be useful to look at team dynamics from the real-time point of view of a team actually working in a state of effective teamwork. Teams exhibiting the most desirable teamwork were best able to solve the riddles of such teamwork.

The decision to devote the BootCamp teams' efforts to resolving the issues of bringing teams to the effective state they were enjoying was a productive innovation. Teams in a newly gained high-performance state produce extraordinary results. When they examine the conditions and elements of their own high performance, as it occurs, the quality of insight is substantial.

Almost every BootCamp team has experienced the following flash of insight: If teamwork itself could be made more efficient and direct, then the team members would be able to find the solutions to the big problems that vexed them. This knowledge could then be leveraged to enhance their other endeavors.

High-performance teams typically acquire their reputations by accomplishing the specific goals they set for themselves. For example, a great basketball team wins many basketball games. The players are not remembered for their contributions to the art and science of team enhancement, but for putting balls through hoops. Achieving a team's original goal is a task not directly related to explicitly uncovering the dynamics of team formation. In the case of the BootCamp teams, the presenting task became the discovery, refinement, and codification of practices that would always lead to the formation of great teams.

As one BootCamp led to the next, we began capturing the best practices employed by the teams, and we encoded these behaviors to make them easily transmissible. These lessons from the BootCamp experiences gradually evolved into The Core protocols. When a team applies The Core protocols consistently, it will produce superior results.

The booting process stimulated by The Core protocols can be ongoing, yielding more efficient and capable groups. The lesson that the booting process continues in a general way is reinforced vividly when we see every new BootCamp team learn more, do more, and add more to the richness and the reproducibility of the "multipersonal" patterns and protocols that lie at the heart of The Core.And that's our story—how we watched The Core protocols emerge.

The Elements of The Core

We have encoded information regarding team behaviors that in our experience will invariably increase any team's desirable results. We have organized the information in a small group of textual structures that make up The Core.

THE FOUR CORE STRUCTURES

  1. Patterns
  2. Antipatterns
  3. Definitions
  4. Protocols

To the potential adopter, The Core protocols are the most significant of these four classes of information. The Core patterns and antipatterns articulate the reasons behind many of the choices we have made as designers of The Core protocols, but The Core protocols are the elements that actually specify—in a detailed, formal way—our recommended personal and team behaviors. The Core protocols have been developed and experimented with through many iterations, and have been used by many people over significant periods of time. We are confident that their consistent and correct application will yield very good results. Even if all the ideas in The Core patterns and antipatterns are mortally flawed, use of The Core protocols will still produce the best results of any set of practices we've seen or tried. If we do not understand why they work, we do understand that they work.

Additionally, it should be noted that the common understanding and practical acceptance of some terms included in The Core definitions are required in order to properly apply some of The Core protocols. To the extent that this is so, those Core definitions must necessarily be given equal weight to The Core protocols.

PATTERNS

A pattern is a standardized way of efficiently communicating the solution to a problem in a context; a pattern should generate something and tell you how to generate that something. Patterns promise particular results and consequences if you apply them. A pattern for a dress, for example, will support you in creating the dress it promises but limit the wearer's options. Use of The Core patterns has repeatedly generated teams that perform better than the teams originally expected of themselves.

The word "pattern" has come to have a special meaning for software developers. The idea of patterns in software descends from a special use of the term first articulated by Christopher Alexander, thinker and architect, in the 1970s.1 He created a structure for documenting patterns and collections of patterns called "pattern languages." These pattern languages were used to encode and communicate important ideas about the practice and purpose of architecture.

Patterns are a means of transmitting general solutions to common problems. The special software or architectural sense of the word "pattern" is not really all that different from the usual use of the word. If you have a pattern, especially one that has been consistently successful in its application, you don't have the thing itself, but you do have a head start in making the thing, or learning enough to make it or use it. For this reason, patterns have come to be widely written about and discussed as a communications mechanism in the software field.The classic definition of a pattern of this type is "A solution to a problem in a context." People being what they are, there is some dispute about the definition of software patterns. Generally, software patterns are abstract solutions to recurrent technical problems faced by programmers. They are a way for a programmer to understand and acquire a language for discussing problems. This can lead to the accumulation of intelligence. Theoretically, patterns enable the re-use of the best thinking done to date, and allow a pattern consumer to access the body of solutions available.

We define patterns as software for your head. Our pattern-based software, like other applications of the pattern concepts, provides solutions to common problems. The patterns in The Core contain information, procedures, and constraints that you can "load" into your mind. Once loaded or learned, you can apply them. Your teammates can do the same, and then all can share in what we believe is a rich source of psychological, linguistic, and behavioral resources. Apply these patterns however and whenever you care to.

The Core patterns apply to the shaping of a group's thinking, and the making and execution of its decisions. Our goal in supplying patterns of this type isWe want to create a world wherein a group's behaviors consistently achieve that group's predetermined goals.

ANTIPATTERNS

These are patterns that describe common solutions that yield undesirable results. In effect, they are false patterns, patterns that reliably fail. For every antipattern in The Core, we present a pattern or a protocol (or both) that has provided a satisfactory solution to the problem many times.

"One-eighty" is the somewhat whimsical name we have given to a special type of phenomenon we have observed more often than we expected. A one-eighty is an idea that expresses conventional wisdom, but it yields undesirable results and does so in the most abysmal way conceivable. A one-eighty is so wrong-headed that, if instead of following the idea in question, a person performed steps precisely opposite to those specified or suggested, he would actually achieve the ostensible goal of the one-eighty. In other words: Conventional wisdom is often real wisdom, but encoded as the opposite folly.

DEFINITIONS

Most software systems have their own definitions of special terms. Generally, the system authors define these terms. Naturally, the definitions of such terms are local in scope.

The words used in The Core are found in everyday English. To reduce complications caused by the availability of the same words for everyday use and their specific application and meaning in the context of The Core, we supply a lexicon of Core definitions.

  • The purpose of the lexicon is to specify the exact meaning of what might otherwise be overloaded words or phrases. These may or may not have general usage beyond The Core, but, if they do, we define them locally because we found that their application typically lacked precision.
  • The definitions are designed to increase the results of your team, not necessarily to provide any real truth-value beyond the scope of the team life. The Core's definitions are not dictionary definitions. They are tokens in a system.
  • The definitions are somewhat arbitrary and must be accepted for the system to function. For the purpose of applying The Core, they are best seen as straightforward but local axioms, arbitrary little chunks of meaning. Just "givens."
  • These definitions provide the linguistic material required to construct and use The Core. The definitions are just a part of the rules of the game. They are special constraints that can channel substantial power to and from the team playing the game.

Wherever possible, we have tried to use words that do have some generally accepted meaning close to what we are trying to convey in our application of the term. We dislike making up new words. This way, anybody can get a sense of what is being discussed by a Core team without recourse to the lexicon.

PROTOCOLS

Almost all team activity is untouched by The Core. The Core protocols are meant to ensure that a few important results-oriented behaviors will be attained by a given team with a

  • Previously unavailable degree of reliability
  • Higher than usual degree of efficiency
  • More uniform distribution of accountability

Any team can use The Core protocols to achieve these goals. The rest of the time, team life goes on, as the team desires.

When adopted, Core protocols will provide teams with a reliable means to efficiently achieve at least the following:

  1. Group interpersonal connection with an increased level of access to one another
  2. Collective, unanimous decision making and related accountability distribution
  3. Team and personal alignment
  4. Achievement of a shared vision, including
  • Long-term or far vision
  • Short-term or version-oriented vision
  • Personal commitment to personal and team goals
  • Team commitment to personal and team goals

Many teams have never experienced these achievements. The Core protocols turn them into everyday activities.

The Core protocols do not predefine or limit2 the content transmitted between connecting parties. Instead, the protocols provide the opportunity to transmit and receive the content deemed important by the parties.

The protocols in The Core are conceptually simple, memorable, and practical. We have found each one to be extremely effective; many teams have used them, and they quickly become second nature for the teams. While we have no desire to formalize normal team interplay, we do provide sufficient structure so that teams can enjoy particular kinds of interplay that are as consistently high quality, highly reliable, and as results oriented as a team might desire.

1. See, for example, Christopher Alexander, et al., A Pattern Language (Oxford University Press, 1977) and Alexander, The Timeless Way (Oxford University Press, 1979).

2. Beyond supporting the normal limits expected in an environment allowing civilized discourse, at any rate.

Read More Show Less

Table of Contents

Acknowledgments.

Introduction.

I. CHECK IN.

1. The Elements of Check In.

Overcoming Distance.

The Check In Protocol.

The Check Out Protocol.

The Passer Protocol.

Connection.

Problem Behaviors.

Patterns Synergistic with Check In.

2. Check In Patterns and Protocols.

Pattern: Check In.

Additional Discussion of Check In.

Pattern: Check Out.

Pattern: Passer.

Pattern: Connection.

3. Check In Antipatterns.

Antipattern: Too Emotional.

Antipattern: No Hurt Feelings.

Antipattern: Wrong Tolerance.

4. Other Patterns in the Check In Family.

Pattern: Team = Product.

Pattern: Self-Care.

Pattern: Thinking and Feeling.

Pattern: Pretend.

Pattern: The Greatness Cycle.

II. DECIDER.

5. The Elements of Decider.

Other Decision-Related Elements.

Antipatterns.

6. Decider Patterns and Protocols.

Pattern: Decider.

Analysis of Decider.

Pattern: Resolution.

Pattern: Work with Intention.

Pattern: Ecology of Ideas.

7. Decider Antipatterns.

Antipattern: Resolution Avoidance.

Antipattern: Oblivion.

Antipattern: Turf.

Antipattern: Boss Won't Give Power.

Antipattern: Team Quackery.

III. ALIGNING.

8. The Elements of Alignment.

Personal and Team Alignment.

9. Alignment Pattern and Protocol.

Pattern: Alignment.

10. Alignment Antipatterns.

Antipattern: Not Enough People.

Antipattern: Align Me.

11. Alignment Patterns.

Pattern: Personal Alignment.

How and Why Alignment Works.

Pattern: Investigate.

Pattern: Receptivity.

Pattern: Web of Commitment.

Pattern: Ask for Help.

IV. SHARED VISION.

12. The Elements of Shared Vision.

Aspects of Shared Vision.

Patterns Involved in the Shared Vision Process.

13. Shared Vision Patterns and Protocols.

Pattern: Shared Vision.

Pattern: Metavision.

Pattern: Far Vision.

Pattern: Version.

14. Shared Vision Antipatterns.

Antipattern: Blinder.

Antipattern: Technicality.

Antipattern: Recoil.

Antipattern: Feedback.

15. The Perfection Game Pattern 3

Playing and Perfecting.

V. APPENDIXES.

Appendix A. The Core Lexicon.

Appendix B. BootCamp Material.

Appendix C. The Core Protocols V. 1.0.

Index.

Artwork.

Authors. 0201604566T01022002

Read More Show Less

Preface

The Core V. 1.0 Background

We didn't create The Core. Instead, we watched it grow. We did, however, along with John Rae-Grant, create the set of initial conditions under which The Core protocols, or something very much like them, would almost certainly emerge. Over the years, we have maintained healthy conditions for Core evolution. Along the way, we also pruned the tree from growing into a few false directions. And we added resources: our own money, time, focus, and stamina. We protected it. Took notes. Tried it out. Passed it out.

A proper credit also has to include the hundreds of product developers and other students from around the world who contributed to The Core's development over the years. Crediting one person or segment of contributors exclusively would be inaccurate, however. The real story is both simpler and more complex.The emergence of The Core was in some measure a result of our experiences in 1994-95. We were working for a commercial software company, leading a development team of approximately 150 people. We used a homegrown aphorism to help us try new ideas:

Team = Software

That's the idea. Because of its many virtues, despite its deficits, and regardless of others who have had the same thought, this maxim became a bit of a mantra for us. During stressful times, when we were tempted to retreat from the overwhelming complexity of the software development tasks; when the confusion and disorientation were really getting to us; when schedules were slipping and goals receding and prospects were looking pretty grim indeed. Then, just when we needed it most, someone in our group would invariably come up with a new idea, would provide a fresh point of view based on "Team = Software." "I get it," he might say, and then rattle off some new application of "Team = Software" that could apply to our situation. Occasionally, these ideas were profound; more often they weren't. They were almost always useful, however.

The essence of the "Team = Software" philosophy is that the behavior of a team maps directly to the qualities of its product, and vice versa. If you want a product with certain characteristics, you must ensure that the team has those characteristics before the product's development.

We also realized that everyone has a product or provides a service. Everyone produces a concrete expression of his value system that carries that person's virtues and vices out into the world.

What was our leadership team making? We moved through the hierarchical levels in our organization and answered two pertinent questions at each interesting point: Who is the team here? And what is its product?

Let's call the team of frontline developers the Level I team. Level I makes the actual product. The managers of this team constitute the Level II team. Its product is the Level I team. When applying the "Team = Software" philosophy, the team on one level is the product of the team at the next higher level. If the Level II team sees an undesirable trait in the Level I team, it must be an expression of or reflection of Level II teamwork and the Level II team members. This pattern applies to teams at all levels, right up through the corporate ranks.

This idea may seem clever, obvious, fanciful, or just plain wrong-headed, but to us it was certainly helpful. Using this model, no one can hide from accountability. In our situation, even though we were bosses, we could not fault a team for lacking a virtue, unless and until we had personally demonstrated it. Nor could we expect any remedy that we weren't personally modeling. On the one hand, this realization was depressing, because there really was no escape: Responsibility inevitably migrated upward and weighed heavily from time to time on our well-paid, if under-exercised, shoulders. On the other hand, this realization offered an incredibly hopeful perspective as something more, something immediate, something completely within our control that was available to remedy any shortcomings of the team.

If we saw something screwed up somewhere or noticed some good fruit dying on the vine, we could immediately find and fix the problem. To inspire other team members to go get that fruit before it died, we would gather and visibly devour tantalizing fruit that had gone unpicked in our own neck of the woods.If we wanted any property to materialize on the Level I team, we would have to incorporate that property into our own behavior. This change in behavior was conceptually simple, but challenging to implement. In any case, keeping this basic framework in mind exposed many novel approaches to team problems. When we first applied this perspective, so many new possibilities opened up at such a rapid pace that we were unable to keep up with them. Although many little tests and a few big ones did yield the desired results, we saw so many new solutions to problems that had plagued us for years that we hardly knew where to begin. We quickly realized that we couldn't possibly conduct sufficient experiments to develop a full understanding of precisely how useful the formula was; to discover where it failed; or to see where the behavior it inspired might lead. We wanted to explore its dynamics and map its etiology in the systems we believed it governed--that is, check it out all the way.

Unfortunately, the experimental opportunities in a commercial software development effort are necessarily limited. A major obstacle is the simple passage of calendar time. A large commercial software project can take months or years. The possibilities we were seeing appeared so valuable, however, that even a few months seemed far too long for each cycle if we were to learn everything possible. With millions of dollars at stake on a single development effort, radical experimentation seemed risky. The number of variables with which we could tinker was low. Together, the sluggishness of "real-world" calendar time and the responsibilities of prudent business practices worked against the idea of implementing the sustained, radical, and rapid experimentation that we envisioned. Still, we thought big breakthroughs in team dynamics were possible--breakthroughs that could make collaboration simpler and more effective for any team.

To study this material in depth, we had to complete a development cycle in a much shorter time. Life itself was too short to go through enough development cycles. Even a very busy, unusually stable, and highly focused development manager could--if he stayed with the task for a long time--expect to oversee 10 to 20 projects in one professional lifetime. Many of these projects would use essentially the same teams, reducing the diversity of team sources that would enrich the manager's education and hasten experimental progress.

In early 1996, to accelerate the rate and breadth of our experiments, we went out on our own and established a laboratory devoted to the study and teaching of teamwork. The ultimate existence of The Core protocols became a virtual certainty when we decided how we would operate the new lab, which we named "Software Development BootCamp." The principal experiment conducted would be a recurrent product development simulation, lasting five days and nights with a new team each time. It would take place every month or so. The developers would complete four steps:

  1. Form a team.
  2. Envision a product.
  3. Agree on how it would be made.
  4. Design and build it.

At the end of the week, the teams would have to deliver their products on time, or stay longer to do so, or not, as they chose.

We knew that we could successfully conduct such a product development effort, even leading it personally, if needed. We had done just that for many years, earning our living in a variety of environments. We had sufficient information, tips, techniques, and useful practices to transmit high value to most students. We could teach them practices that could ensure the successful outcome of their own product development efforts, now or later, simulated or not.

We had already gained, organized, and articulated considerable knowledge from our experiences in leading or otherwise contributing to dozens of development efforts, most of which proved quite successful. This body of knowledge would serve as the starting point for the first BootCamp teams. Even if we learned nothing during BootCamp, we still would have plenty to offer.

BootCamp has allowed us to effectively compress a software development cycle into a five-day experience. In five days, students learn what would normally require a long development cycle. The intense BootCamp experience includes all of the failures and triumphs that occur with normal team formation; the creation of a team-shared vision; and the design, implementation, and delivery of a product. The days in each BootCamp are packed with accelerated team dynamics; what usually takes a year or more is created in a few long days and nights of exceptionally deep engagement.

The many new insights from BootCamp emerged at a vastly increased clip. The learning pace was accelerated by our experience of working intimately with some 60 different software development teams. We first helped to create the team, and then their products. We experienced complete development cycles with incredible frequency and velocity--one or two times per month at peak periods. Working with teams of every kind and composition, and working before and after BootCamp, we applied what we learned to our own teamwork.

One additional factor led to the creation of The Core protocols, and originated in our standard assignment to the students. Each team would have to build a product in one week. But what product would the BootCamp teams make?

At one level, BootCamp is conceptually simple: We assemble a group of software developers. Sometimes the students are members of a preexisting team. Sometimes they represent as many types of developers as possible: corporate employees, entrepreneurs, computer scientists, software testers, writers, editors, graphic artists, coders, managers, executives, program and project managers, and producers. Often, there will be nondevelopers in attendance: nurses, teachers, homebodies, consultants, and press members. We give each new team-in-waiting a single assignment:

Design, implement, and deliver a course that teaches you everything you need to know to ship great software on time, every time.

This assignment has remained unchanged since the first BootCamp. It seemed to us that it would be useful to look at team dynamics from the real-time point of view of a team actually working in a state of effective teamwork. Teams exhibiting the most desirable teamwork were best able to solve the riddles of such teamwork.

The decision to devote the BootCamp teams' efforts to resolving the issues of bringing teams to the effective state they were enjoying was a productive innovation. Teams in a newly gained high-performance state produce extraordinary results. When they examine the conditions and elements of their own high performance, as it occurs, the quality of insight is substantial.

Almost every BootCamp team has experienced the following flash of insight: If teamwork itself could be made more efficient and direct, then the team members would be able to find the solutions to the big problems that vexed them. This knowledge could then be leveraged to enhance their other endeavors.

High-performance teams typically acquire their reputations by accomplishing the specific goals they set for themselves. For example, a great basketball team wins many basketball games. The players are not remembered for their contributions to the art and science of team enhancement, but for putting balls through hoops. Achieving a team's original goal is a task not directly related to explicitly uncovering the dynamics of team formation. In the case of the BootCamp teams, the presenting task became the discovery, refinement, and codification of practices that would always lead to the formation of great teams.

As one BootCamp led to the next, we began capturing the best practices employed by the teams, and we encoded these behaviors to make them easily transmissible. These lessons from the BootCamp experiences gradually evolved into The Core protocols. When a team applies The Core protocols consistently, it will produce superior results.

The booting process stimulated by The Core protocols can be ongoing, yielding more efficient and capable groups. The lesson that the booting process continues in a general way is reinforced vividly when we see every new BootCamp team learn more, do more, and add more to the richness and the reproducibility of the "multipersonal" patterns and protocols that lie at the heart of The Core.And that's our story--how we watched The Core protocols emerge.

The Elements of The Core

We have encoded information regarding team behaviors that in our experience will invariably increase any team's desirable results. We have organized the information in a small group of textual structures that make up The Core.

THE FOUR CORE STRUCTURES

  1. Patterns
  2. Antipatterns
  3. Definitions
  4. Protocols

To the potential adopter, The Core protocols are the most significant of these four classes of information. The Core patterns and antipatterns articulate the reasons behind many of the choices we have made as designers of The Core protocols, but The Core protocols are the elements that actually specify--in a detailed, formal way--our recommended personal and team behaviors. The Core protocols have been developed and experimented with through many iterations, and have been used by many people over significant periods of time. We are confident that their consistent and correct application will yield very good results. Even if all the ideas in The Core patterns and antipatterns are mortally flawed, use of The Core protocols will still produce the best results of any set of practices we've seen or tried. If we do not understand why they work, we do understand that they work.

Additionally, it should be noted that the common understanding and practical acceptance of some terms included in The Core definitions are required in order to properly apply some of The Core protocols. To the extent that this is so, those Core definitions must necessarily be given equal weight to The Core protocols.

PATTERNS

A pattern is a standardized way of efficiently communicating the solution to a problem in a context; a pattern should generate something and tell you how to generate that something. Patterns promise particular results and consequences if you apply them. A pattern for a dress, for example, will support you in creating the dress it promises but limit the wearer's options. Use of The Core patterns has repeatedly generated teams that perform better than the teams originally expected of themselves.

The word "pattern" has come to have a special meaning for software developers. The idea of patterns in software descends from a special use of the term first articulated by Christopher Alexander, thinker and architect, in the 1970s.1 He created a structure for documenting patterns and collections of patterns called "pattern languages." These pattern languages were used to encode and communicate important ideas about the practice and purpose of architecture.

Patterns are a means of transmitting general solutions to common problems. The special software or architectural sense of the word "pattern" is not really all that different from the usual use of the word. If you have a pattern, especially one that has been consistently successful in its application, you don't have the thing itself, but you do have a head start in making the thing, or learning enough to make it or use it. For this reason, patterns have come to be widely written about and discussed as a communications mechanism in the software field.The classic definition of a pattern of this type is "A solution to a problem in a context." People being what they are, there is some dispute about the definition of software patterns. Generally, software patterns are abstract solutions to recurrent technical problems faced by programmers. They are a way for a programmer to understand and acquire a language for discussing problems. This can lead to the accumulation of intelligence. Theoretically, patterns enable the re-use of the best thinking done to date, and allow a pattern consumer to access the body of solutions available.

We define patterns as software for your head. Our pattern-based software, like other applications of the pattern concepts, provides solutions to common problems. The patterns in The Core contain information, procedures, and constraints that you can "load" into your mind. Once loaded or learned, you can apply them. Your teammates can do the same, and then all can share in what we believe is a rich source of psychological, linguistic, and behavioral resources. Apply these patterns however and whenever you care to.

The Core patterns apply to the shaping of a group's thinking, and the making and execution of its decisions. Our goal in supplying patterns of this type isWe want to create a world wherein a group's behaviors consistently achieve that group's predetermined goals.

ANTIPATTERNS

These are patterns that describe common solutions that yield undesirable results. In effect, they are false patterns, patterns that reliably fail. For every antipattern in The Core, we present a pattern or a protocol (or both) that has provided a satisfactory solution to the problem many times.

"One-eighty" is the somewhat whimsical name we have given to a special type of phenomenon we have observed more often than we expected. A one-eighty is an idea that expresses conventional wisdom, but it yields undesirable results and does so in the most abysmal way conceivable. A one-eighty is so wrong-headed that, if instead of following the idea in question, a person performed steps precisely opposite to those specified or suggested, he would actually achieve the ostensible goal of the one-eighty. In other words: Conventional wisdom is often real wisdom, but encoded as the opposite folly.

DEFINITIONS

Most software systems have their own definitions of special terms. Generally, the system authors define these terms. Naturally, the definitions of such terms are local in scope.

The words used in The Core are found in everyday English. To reduce complications caused by the availability of the same words for everyday use and their specific application and meaning in the context of The Core, we supply a lexicon of Core definitions.

  • The purpose of the lexicon is to specify the exact meaning of what might otherwise be overloaded words or phrases. These may or may not have general usage beyond The Core, but, if they do, we define them locally because we found that their application typically lacked precision.
  • The definitions are designed to increase the results of your team, not necessarily to provide any real truth-value beyond the scope of the team life. The Core's definitions are not dictionary definitions. They are tokens in a system.
  • The definitions are somewhat arbitrary and must be accepted for the system to function. For the purpose of applying The Core, they are best seen as straightforward but local axioms, arbitrary little chunks of meaning. Just "givens."
  • These definitions provide the linguistic material required to construct and use The Core. The definitions are just a part of the rules of the game. They are special constraints that can channel substantial power to and from the team playing the game.

Wherever possible, we have tried to use words that do have some generally accepted meaning close to what we are trying to convey in our application of the term. We dislike making up new words. This way, anybody can get a sense of what is being discussed by a Core team without recourse to the lexicon.

PROTOCOLS

Almost all team activity is untouched by The Core. The Core protocols are meant to ensure that a few important results-oriented behaviors will be attained by a given team with a

  • Previously unavailable degree of reliability
  • Higher than usual degree of efficiency
  • More uniform distribution of accountability

Any team can use The Core protocols to achieve these goals. The rest of the time, team life goes on, as the team desires.

When adopted, Core protocols will provide teams with a reliable means to efficiently achieve at least the following:

  1. Group interpersonal connection with an increased level of access to one another
  2. Collective, unanimous decision making and related accountability distribution
  3. Team and personal alignment
  4. Achievement of a shared vision, including
  • Long-term or far vision
  • Short-term or version-oriented vision
  • Personal commitment to personal and team goals
  • Team commitment to personal and team goals

Many teams have never experienced these achievements. The Core protocols turn them into everyday activities.

The Core protocols do not predefine or limit2 the content transmitted between connecting parties. Instead, the protocols provide the opportunity to transmit and receive the content deemed important by the parties.

The protocols in The Core are conceptually simple, memorable, and practical. We have found each one to be extremely effective; many teams have used them, and they quickly become second nature for the teams. While we have no desire to formalize normal team interplay, we do provide sufficient structure so that teams can enjoy particular kinds of interplay that are as consistently high quality, highly reliable, and as results oriented as a team might desire.

1. See, for example, Christopher Alexander, et al., A Pattern Language (Oxford University Press, 1977) and Alexander, The Timeless Way (Oxford University Press, 1979).

2. Beyond supporting the normal limits expected in an environment allowing civilized discourse, at any rate.

0201604566P01022002

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing 1 Customer Reviews
  • Anonymous

    Posted May 12, 2002

    I didn't plan to buy this book...

    I was looking for a good book on Pthreads, when the title of this book caught my eye. I picked it up just to see what it was talking about and realized it was a book about team dynamics. I don't normally read software management books; I'm much more interested in doing the development work, and I get turned off by all the management-style-of-the-month books. Sure I've worked on some really bad teams, and maybe a really good one once. Maybe. All that team-building philosophy stuff is important and useful to the unlucky person stuck with managing the team. But not me... Before I could put the book down, I noticed it used familiar words like 'patterns' and 'protocols'. Since they were speaking my language, I decided to browse further to see what they were talking about with all the 'Check In' chapters... I guess I'm getting soft. I bought a book on team dynamics instead of a Pthreads book. Maybe if more developers got soft we'd have better products getting to market faster. Fun. Interesting. Profound. I can tell already this is going to be a classic.

    Was this review helpful? Yes  No   Report this review
Sort by: Showing 1 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)