Online Sample Chapters
Managing Software Teams for Results: Achieving Performance Through Effective Collaboration
Managing Software Teams for Results: Patterns and Protocols
Downloadable Sample Chapter
Click below for Sample Chapter related to this title:
mccarthych01.pdf
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
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:
- Form a team.
- Envision a product.
- Agree on how it would be made.
- 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
- Patterns
- Antipatterns
- Definitions
- 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:
- Group interpersonal connection with an increased level of access to one another
- Collective, unanimous decision making and related accountability distribution
- Team and personal alignment
- 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
Index
AAccountability. See Alignment; Decider
Afraid
CheckIn and, 29-30, 390
defined, 336
GreatnessCycle and, 94, 95 (Table)
Aggregate headgap, defined, 12
Aggregation, Decider and, 135-136, 159, 160
Alexander, Christopher, xx
AlignMe antipattern, 185, 208-213, 380-381
Alignment
about, 20-21
in BootCamp, 368, 372, 380-381
defined, 232n
elements of, 185, 187-188
team scenario with, 182-184
Alignment antipatterns, 199-213. See also AlignMe
Alignment depth, 226
Alignment evidence, 223, 231
Alignment patterns, 189-193. See also AskforHelp; Investigate; PersonalAlignment; Receptivity; SharedVision; TeamAlignment; WebofCommitment
Alignment protocols, 193, 195-197, 400-401. See also Investigate; PerfectionGame
Anger. See Mad
Antipatterns, xix, xxi-xxii, 336. See also CheckIn
Art space, in BootCamp, 361-363
Asker role/commitments, 256-259, 409-412
AskforHelp pattern, 253-256
AskforHelp protocol
in BootCamp, 365, 368
commitments, 258-259, 411-412
questions about, 259-260
roles, 256-257, 259, 409-411
Attraction, PersonalAlignment and, 233
Autocratic decision-making, 121-122, 146
Awareness, defined, 19BBehaviors, problem, 14. See also WrongTolerance
Bits, defined, 50n
Black hats, 255n, 360, 369-371, 376-377
Blame, caring and, 161-162
Blather
AlignMe and, 208-210, 211, 212, 213
AskforHelp and, 256n
defined, 337
Blinder antipattern, 274, 275, 278, 283, 303-305
Block, defined, 337
Blue hats, 360
BootCamp. See also Black hats; Consultants
about, 358-364
answer key, 365-375
art space, 361-363
CheckIn and, 39n, 379-380
confrontation, 378
establishment of, xvi-xix
facilities liaison, 361
goals of, 364-365, 381
group discussion, 377
hats, 360-361
materials, 353-381
moderators, 378-379
personal participation in, 354-358
psychotherapy, compared to, 375-381
simulation example, 359
staff, 363-364
team assignments, 364
"Boss-as-judge" decisions, 122, 125-126, 146
BossWon'tYield antipattern, 116, 163-165CCare/Caring, defined, 160-161
Censorship, self, 76
Charisma, TeamQuackery and, 172-173
Checked in, defined, 337
CheckIn, 11-17, 23n, 27, 329
CheckIn antipatterns, 14, 53-68. See also NoHurtFeelings; TooEmotional; WrongTolerance
CheckIn patterns. See also CheckOut; Connection; Decider; GreatnessCycle; Passer; Pretend; Self-Care; Team = Product; ThinkingandFeeling
behaviors, problem, 14
benefits of, 42
connection and, 14
discussion, additional, 32-42
distance, overcoming, 11-12
emotions and, 22-25, 33
multiple levels, 34
patterns synergistic with, 15, 17
problem, 19-22
solution, 34
team characteristics with, 4-10, 41-42
CheckIn protocols. See also Group CheckIn; Personal CheckIn
benefits of, 36
in BootCamp, 369, 372, 379-380
components of, 12-13
defined, 25
emotional states, core, 29-30, 35, 36, 37, 38, 39, 55, 94, 95 (Table), 390
evasions, common, 35-36, 38-39
functions, 34, 35
group, 27-28
guidelines, 31, 391
identification, increased, 37
illegal, 36n
meetings, use at, 41-42
presence and, 17, 42
results, 30-31, 37-38, 39, 42
rules, 32, 391
specific "In-ness" commitments, 26-27, 388-389
synopsis, 28-29
team characteristics with, 39-40
when to use, 31, 390-391
CheckOut pattern, 43
CheckOut protocol
commitments, 45, 392
components of, 13
guidelines, 45, 393
results, 44
synopsis, 44, 392
when to use, 44-45, 391, 392
Coaches. See Consultants
Conflict avoidance, defined, 65
Conflict(s). See also Decider; ResolutionAvoidance
CheckIn and, 17
cost of reducing, 93
GreatnessCycle and, 82, 83, 92-94, 96, 97
Confrontation, in BootCamp, 378
Connection. See also CheckIn
in BootCamp, 365
Decider and, 135
defined, 14
FarVision and, 297
Connection pattern, 48-52
"Consensus-style" decisions, 123-124
Consultants
in BootCamp, 361, 363-364, 366, 367, 369, 377
TeamQuackery and, 172
Conway, Mel, 70n
Conway's Law, 70n
Core V. 1.0. See also BootCamp
defined, 338
elements/structure of, xix-xxivv
lexicon,335-351
Core V. 1.0 protocols. See also Alignment; AskforHelp; CheckIn; CheckOut; Decider; IntentionCheck; Passer; Passionometer; PerfectionGame; Resolution; SharedVision; WebofCommitment
licensing agreement, 418-424
overview, 385-387
structural aspects of, xix, xx, xxii-xxiv
Corporate culture, 207
Courage, 91, 94
Culture, corporate, 207
Cynicism, 168-170, 234DDarwin, Charles, 97, 98
Decider
CheckIn and, 26, 27
elements of, 111-115
FarVision and, 300
Passer and, 46
team scenario with, 106-109
Decider antipatterns, 115-116. See also BossWon'tYield; Oblivion; ResolutionAvoidance; TeamQuackery; Turf
Decider patterns. See also Resolution; WorkwithIntention
analysis, 130-137
commitments, 130
outcomes, 130
problem, 117-126
SharedVision and, 270
solution, 126-130
won't get in strategy, 136-137
Decider protocols. See also IntentionCheck
about, 394-395
in BootCamp, 368, 369, 372
commitments, 397
guidelines, 395-396
outcomes, 397
steps of, 126-130
voting, 127 (Table), 129-130, 396-397
Decisions
defined, 119
making, common techniques of, 120-126
unanimity of, 111-112, 114
Definitions, xix, xx, xxii-xxiii, 335-351
Democratic decision-making, 121, 122
Depth
of CheckIn, 338
of presence, 85
Despair, TeamQuackery and, 168-170
Developers, defined, 272
Disbelief, TeamQuackery and, 168-170
Disclosure, 13n
Disintegration, lateness and, 247, 248
Distance, CheckIn and, 11-12EEcologyofIdeas pattern
Decider and, 114-115, 146-147
problem, 146
solution, 147
EcologyofIdeas pattern (Cont.