Software for Your Head Core Protocols for Creating and Maintaining Shared Vision

by McCarthy, Jim; McCarthy, Michele

• ISBN13: 9780201604566
• ISBN10: 0201604566
• Edition: 1st
• Format: Paperback
• Copyright: 2001-12-27
• Publisher: Addison-Wesley Professional

Summary

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 Headis 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

Author Biography

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

Table of Contents

Acknowledgments	xi
Introduction	xiii
PART I CHECK IN	1	(104)
The Elements of Check In	11	(8)
Overcoming Distance	11	(1)
The Check In Protocol	12	(1)
The Check Out Protocol	13	(1)
The Passer Protocol	13	(1)
Connection	14	(1)
Problem Behaviors	14	(1)
Patterns Synergistic with Check In	15	(4)
Check In Patterns and Protocols	19	(34)
Pattern: Check In	19	(13)
Additional Discussion of Check In	32	(11)
Pattern: Check Out	43	(3)
Pattern: Passer	46	(2)
Pattern: Connection	48	(5)
Check In Antipatterns	53	(16)
Antipattern: Too Emotional	53	(10)
Antipattern: No Hurt Feelings	63	(3)
Antipattern: Wrong Tolerance	66	(3)
Other Patterns in the Check In Family	69	(36)
Pattern: Team = Product	69	(5)
Pattern: Self-Care	74	(3)
Pattern: Thinking and Feeling	77	(3)
Pattern: Pretend	80	(2)
Pattern: The Greatness Cycle	82	(23)
PART II DECIDER	105	(74)
The Elements of Decider	111	(6)
Other Decision-Related Elements	114	(1)
Antipatterns	115	(2)
Decider Patterns and Protocols	117	(32)
Pattern: Decider	117	(13)
Analysis of Decider	130	(7)
Pattern: Resolution	137	(3)
Pattern: Work with Intention	140	(6)
Pattern: Ecology of Ideas	146	(3)
Decider Antipatterns	149	(30)
Antipattern: Resolution Avoidance	149	(5)
Antipattern: Oblivion	154	(4)
Antipattern: Turf	158	(5)
Antipattern: Boss Won't Give Power	163	(2)
Antipattern: Team Quackery	165	(14)
PART III ALIGNING	179	(82)
The Elements of Alignment	185	(4)
Personal and Team Alignment	185	(4)
Alignment Pattern and Protocol	189	(10)
Pattern: Alignment	189	(10)
Alignment Antipatterns	199	(16)
Antipattern: Not Enough People	199	(9)
Antipattern: Align Me	208	(7)
Alignment Patterns	215	(46)
Pattern: Personal Alignment	215	(17)
How and Why Alignment Works	232	(4)
Pattern: Investigate	236	(5)
Pattern: Receptivity	241	(6)
Pattern: Web of Commitment	247	(6)
Pattern: Ask for Help	253	(8)
PART IV SHARED VISION	261	(72)
The Elements of Shared Vision	269	(10)
Aspects of Shared Vision	271	(5)
Patterns Involved in the Shared Vision Process	276	(3)
Shared Vision Patterns and Protocols	279	(24)
Pattern: Shared Vision	279	(8)
Pattern: Metavision	287	(3)
Pattern: Far Vision	290	(12)
Pattern: Version	302	(1)
Shared Vision Antipatterns	303	(22)
Antipattern: Blinder	303	(2)
Antipattern: Technicality	305	(8)
Antipattern: Recoil	313	(4)
Antipattern: Feedback	317	(8)
The Perfection Game Pattern	325	(8)
Playing and Perfecting	325	(8)
PART V APPENDIXES	333	(92)
Appendix A The Core Lexicon	335	(18)
Appendix B BootCamp Material	353	(30)
Appendix C The Core Protocols V. 1.0	383	(42)
Index	425	(8)
Artwork	433	(2)
Authors	435

Excerpts

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