McCarthy TeamworX: The Path to Greatness

Al is a DDJ contributing editor. He can be contacted at [email protected].

This is the "C Programming" column in the Annual C/C++ issue, but I am not going to discuss C this time. A recent experience cast light for me on a larger issue that faces all developers, whether they use C, C++, or any other programming language. I have, therefore, decided to talk about that experience this month instead of smaller, less consequential programming issues.

Here is the issue: Our craft does not know how to deliver good software on time and within budget.

I can hear the reaction now. "Terrific, Al, are you just finding that out?" No, I've known it a long time and always reluctantly accepted it as our standard modus operandi, but I may have learned a way to approach the problem, a way that seems to work, exists within all of us, but has yet to be universally turned loose to do its good. You are skeptical? So was I. Read on.

The schedule is our nemesis. Anyone who has worked on a medium to large software development project has experienced a wide range of unhappy and uncomfortable professional situations mostly related to the schedule. Blow the schedule and you blow the budget. Stay within either or both, and the software as shipped delivers less than its promise. Do any of the above, and we invoke management's ire. Usually we blow the schedule, blow the budget, and still ship a minimal (or unacceptable) product, invoking management's wrath. Not to mention that of the users. The only reason we keep our jobs is that we have done exactly what management has come to expect: We commit to a schedule, work our butts off, miss the schedule, deliver junk, get chewed out, and iterate. They can fire us, but they can't replace us with anyone better, and they know it.

According to Pogo, the beloved comic strip possum, "We have met the enemy, and they is us."

Our industry has made no significant progress with scheduling and quality issues in the past 35 years. Slipped schedules, overrun budgets, late deliveries, and compromised quality are and have always been the rule, not the exception. Do you disagree? Why, then, do large software houses routinely ship beta or even alpha quality applications as Version 1.0? Why do users measure our worth by the effectiveness of our technical support rather than the reliability of our software? Why do large installations running complex custom software systems necessarily maintain in perpetuity large staffs of expensive maintenance programmers? How often do we curse the software we use and the bozos who design, implement, and supply it?

Most of us have seen and tried formalized methodologies that claim to address the problems of late, bad software. We shift to better paradigms: higher-level languages; portable software; hierarchical, network, and relational database models; structured programming; object-oriented design; reusable software components. Those are good things, but, as it turns out, not the panacea we seek. We modify our approaches to organization and management: critical path methods; chief programmer teams; egoless programming; structured code reviews; waterfalls. We try different design models: composite design; modular; top-down; bottom-up; inside-out. We use charts, cards, notations, reports, and feedback. We chase fads, fancy, and folly in search of that most elusive of all objectives -- quality software, on time, within budget.

And mostly, we fail.

The proponents and purveyors of the panacea methodologies might argue that we fail because we do not rigorously and conscientiously apply their disciplines. They might be right that we do not, but a revealing question ponders why we do not. A more revealing question asks whether any amount of discipline can successfully guide a team whose members do not share a common vision of its purpose. Seem obvious? Until last week, it did not occur to me to ask that second question.

We developers use contemporary tools to be more productive. The result? At best, a more productive programmer who commits to even more optimistic schedules. Consequently, we miss shorter deadlines. The cycle reminds me of the mythical Foo bird who flies in a spiral of tighter and faster circles until he disappears when he flies up his own...er, you know what I mean.

Off to Boot Camp

I've recently returned from the hills just east of Seattle where I attended the McCarthy TeamworX BootCamp, a one-week workshop about "how to deliver great software on time every time," the very issue that my opening paragraphs discuss. McCarthy TeamworX is the creation of Jim McCarthy, Jeff Beehler, and John Rae-Grant, former Microsoft technical managers who, with Jim's wife Michele, shaped their shared concepts of team creativity into a series of lectures, classes, consulting sessions, and workshops. Their goal is to improve the software development cycle by addressing the problems that plague it most. At Microsoft, Jim managed the Visual C++ development team. During his tenure there, he authored Dynamics of Software Development (Microsoft Press, 1995), a wonderful book that documents many of the principles that TeamworX now teaches. [Editor's Note: Dynamics of Software Development is reviewed in this month's "Programmer's Bookshelf."] A new book is in the works along with other media -- video tape, for example -- that carry this message. Jeff was program manager for several versions of the C/C++ compiler product. John was manager of the MSDN development team at Microsoft, a rising star in that notable executive firmament, and he walked away from its potential to pursue with Jim the TeamworX objectives. We are the better for that selfless act.

I approached this exercise in what TeamworX calls "experiential learning" with a healthy dose of skepticism. After all, I've been shipping late software that sucks for over 30 years now, and I've tried most of the miracle methodologies. I've got experience! What could these folks possibly know that I do not?

Let me say up front that my description here may not do justice to what BootCamp offers and what I learned -- not that I'm often at a loss for words, but these are lessons that must be learned rather than taught. I have always held that learning complex concepts is a process of discovery and that teaching them is the efficient -- maybe even passive -- management of that process. You just had to be there.

The Process

The underlying theme of the BootCamp (in my interpretation, that is) is that greatness results when a team's members share a common vision of its goals and when they work effectively as a team to resolve personal conflicts in ways that do not compromise the personal visions of the individuals or the shared vision of the team.

Shared vision seems on the surface to be a simple enough goal to attain -- give everyone unambiguous requirements and design specifications, send them off to write code, and have them regularly report their status to management. That model is the traditional approach to team management, and, no matter the methodologies, paradigms, potions, and elixirs that you apply, that model is the foundation of most contemporary software development projects. But most of us as individuals are burdened with personal baggage and agendas that tend to obstruct shared vision. A team nears shared vision when, as a unit, the team recognizes all those individual issues. The team cannot arrive at shared vision until it understands and deals with those issues. The team must respect each personal issue and translate it into a constructive objective for the individual that the team can nurture and support in ways that contribute to the individual's fulfillment and the team's success. BootCamp creates an environment in which, through simulation of a team-driven project, you learn how to do that.

At BootCamp, the attendees are the team. Experiential learning leads the team through a simulation that carefully walks what TeamworX calls the "path to greatness." That path begins with the achievement of team integrity -- a mutual awareness of the team's objectives. Next comes conflict, where members of the team differ about aspects of achieving that mutual objective. Conflict inspires passion, which, properly managed and channeled, resolves conflict, whereupon the path to greatness is realized. At first, that lexicon of catchy phrases -- and there are more to come -- is a mere set of abstractions with little meaning to the inductee, the raw recruit, the boot (to continue the boot camp metaphor). It is the purpose of the simulation to give meaning to these abstractions and make them concrete in time for graduation.

The first step toward shared vision is personal alignment, a process wherein each team member expresses his or her personal objectives to be realized as a member of the team. We had our first such session with the entire team in attendance. A member of the staff asks questions that encourage the team member to examine the underlying motives for his or her objectives and reveal what might be preventing the realization of those goals. This exchange, which includes comments from other team members, can become quite introspective, can involve some emotion, and can take quite a bit of time. Consequently, after the first such session, we divided into three groups, each group having six team members and two staff members. The result of each session is a statement of personal vision expressed in the form of a personal objective. As an example, my objective was, "I want to come out of hiding and learn to take an effective role in peer relationships," reflecting my desire to address problems that compromise my effectiveness in team situations. Without going into details, I confess here that this process allowed me to discover an underlying concern -- a personal reaction to a traumatic experience -- that profoundly influenced my professional decisions in the years that followed. Like I said, you had to be there.

Personal alignment is just that -- personal -- and not about the project and its objectives. Only after everyone completes personal alignment do you address the mundane issues of the simulated project.

As personal alignment proceeds, the simulation continues. We meet for the first time the dreaded management, roles played by two staff members who wear black hats. Our first encounter reinforces the team's predisposition that management is clueless. We receive our project assignment, and we commit to deliver estimates and a schedule. The project is not cut-and-dried. It contains an element of recursion that is difficult to comprehend. We do not know what management wants. An accurate reflection of reality. We do not know what the staff -- outside the simulation, that is -- expects. Team conflicts arise as we miss deadlines and fail to honor commitments in pursuit of the higher objectives of understanding the mission and attaining shared vision. The outcome of my particular team is unimportant here except to say that we were successful. Every team's experience beyond this point is unique due to the diverse, dynamic nature of different aggregates of different people and due to the self-directing freedom that the staff affords us.

Somewhere along the way, the simulation takes on a life of its own and becomes reality. You always know that the end is in sight because you have to go home on Friday, but for the moment, the team's success is the most immediate priority in your life. Unless you hold out. No one does.

The Team

Ours was a diverse team of eighteen. Thirteen of the members were from one company, several of whom were not software developers but were in marketing and other areas related to their company's problem domain. Two team members came from a company that builds developer tools.

The team included a Marine Corps major who provides technical guidance for 250 civilians and 250 military personnel in a large software development project that has been underway for over twenty years. I was the only journalist. One member, the team's only female, wanted to see if these techniques apply in a musical team, a vocal quartet.

The five of us who were not from the one company were accused of being TeamworX "plants," an affectionate tag that persisted until the very end.

The Marine came on strong and exhibited characteristic enthusiasm for the mission and unbridled optimism for the team. He was the first to urge us not to exclude management from the process but to embrace them as if they, too, were team members. In an offline conversation with a few of us, he wondered rhetorically how many of the team members were prepared to die for their management as he had been trained to do. To me, that was one of the most moving and revealing thoughts of the week. I nicknamed him "Buzz Lightyear." Buzz had a substantial influence on the team. He erased many preconceived notions that tend to stereotype his culture. Buzz was the team's unofficial morale officer all week long, never losing his passion and spirit in team sessions, on the volleyball court, at the pool table, or at a local pub as chairman of an ad hoc team formed to enhance, for one evening, the social life of the team's only male bachelor.

Our only female member contributed in ways that she might not have done if the gender balance had been more typical. BootCamps usually have a more balanced male to female ratio. She expressed an early concern that the dominant male role would try to push her contributions to the background as could happen in such a numerically male-dominated society. She was concerned also that, because she was not a software developer, the team would not accept her as a peer. Then she assuaged her own concerns by taking an active and influential role in the simulation. In one scenario, she played before-and-after roles of a programmer who was angry at a management decision. Her convincing performance not only demonstrated that she had been assimilated into this awesome and powerful group, but she earned our respect in the process. Then she touched the hearts of everyone present at closing ceremonies by singing a song about heroism. We would not have been the same team without the textures that this fine person added to our makeup.

Every team member contributed significantly and profoundly to the simulation, and I wish I had space here to discuss them all. During personal alignment, I remarked that this group was the most articulate gathering I had ever joined. Everyone spoke with authority and purpose. No one hemmed or hawed. Everyone was certain of his or her words and ideas even when speaking of uncertainty. John replied that eloquence is the product of clarity, a characteristic that team members find and share through this process; what I had found to be remarkable is typical of teams who enjoy shared vision.

Throughout the simulation, the team has the support and counsel of the TeamworX staff who play the roles of consultants to the team for the development of the project. The staff also shift into other roles, such as the black-hatted management. They leave us to our own devices with respect to how we organize and proceed. To alter our direction, when they think we are on an inappropriate track, they call a huddle, form in a circle in the center of the room, and discuss the issue as if we were not there. We are allowed to hear their concerns and proceed however we want. They use the same method to bust one another's chops over various internal nonsimulated TeamworX conflicts, which allowed us to see the process at work in a real situation.

An overriding theme throughout BootCamp is that you don't have to do anything that you don't want to do. It's comforting to know that rule at the outset when you don't know what to expect. No one invoked the privilege the whole week except, perhaps, for my roommate, who decided early on that he needed a quieter sleeping environment. That's odd; Judy has never complained. Must have been part of the simulation. There were a few personal times out, but eventually, everyone's participation was complete and comprehensive. I have never, in my many years in this business, been on a team with such a clear shared vision as to its intent and purpose.

Humor permeates the week. If you say something funny, they hit a gong and post your witticism on the "wall of greatness." The sayings are supposed to reflect great wisdom, but usually they are one-liners that touch a nerve in a particular moment. People who are direct and to the point with well thought-out, concise, unambiguous language tend not to get gonged very much. Others who like to turn a phrase and get a laugh get gonged more than their share. Consequently, jokes get more credit than wisdom does. Maybe humor is the greatest greatness of them all.

Does BootCamp Work?

The jury is still out on TeamworX's success rate because they have been at it only a short time (eight BootCamps in as many months) and are still collecting empirical data. However, teams in the real world who achieve and realize shared vision report a 400 percent improvement in reaching their objectives. And Jim, Jeff, and John have been using and refining these techniques for many years in their professional lives before TeamworX. The proof is in the pudding; graduates have reached consensus. They say it works.

I can offer my conclusions based only on my experience and observations. Eighteen of us left the camp agreeing that our original healthy skepticism had been replaced by optimism and enthusiasm for this concept. There were no holdouts. This one factor is a compelling indication of the effectiveness of the program. These are strong people, every one of them. Most people, irrespective of strength, are subject to intense psychological influences, and BootCamp involves a small measure of that. This human characteristic explains why some people in times of vulnerability hide themselves in cults. The comfort given by the inner support group is a preferred alternative to the indifference received from the outer world. In this case, though, the inner influence is good because it equips you with tools to take into that outside world. Mind you, there were plenty of nervous jokes such as "Don't drink the Kool-Aid," "No pudding for me, thank you," and "When do we get behind the comet?" But they were only jokes.

Buzz was perhaps the hardest sell of all. I asked him privately from time to time, "Are you buying into all this?" He admitted that some of his private skepticism, which his public enthusiasm was masking, had persisted, which made me wonder if he might be faking some of that in-session gung ho super-positive Buzz Lightyear attitude purely out of habit. "Let's take that hill!" Then something -- I don't know what -- made a substantial impact on him. Shortly after midweek, as the team approached shared vision, I asked the question again. Buzz looked me squarely in the eye and said without hesitation, "Al, this stuff works."

Recommendations

My readers know that I do not endorse anything lightly, but I'll go out on a limb here -- an appropriate position because at BootCamp I seem to have been regarded as the wise owl Al, probably because I was a bit (only a bit) older than the others. Here is what I recommend: If you are about to form a software development team, form it and then send it en mass to BootCamp. If you already have a team and are concerned about schedules (who isn't?) send everyone -- managers and workers -- to BootCamp. Either way I predict that you will recover the cost in short order. Real tangible benefits will be seen in the successes of your team. As you add members to the team, send those new people to BootCamp.

Don't make the same mistake that one of my employers made in the 1960s. Consulting counselors conducted "encounter groups" of so-called "sensitivity sessions" in woodsy retreats amidst the nuts, berries, flora, and fauna far from the burgeoning masses and the hustle and the bustle. My employer sent all the senior and project managers and none of the line managers and project workers. When the bosses returned to work a week later, they were all touchy-feely with one another for a couple of days. We workers were mostly confused and frightened as our managers, freed from their former stoicism, roamed from office to office, getting all weepy, hugging one another, asking how one another felt about this and that, and freely expressing their feelings about one another's ideas and suggestions, all of which was followed by more hugging and teary eye contact. After a few days, the effects wore off, the managers became themselves again, and everything returned to business as usual. Don't make that mistake. Send everyone.

What does it cost? TeamworX quotes a sliding scale that peaks at $5500 per attendee and slides downward depending on variable factors that I do not know about. Cut your own deal. It's worth it whatever the cost. Jim McCarthy said to me, "We've never turned anyone down," and, "This is not about money."

For details, case studies, and the comments of graduates, check out http://www.teamworx.com/.

Reentry

What happens when you leave the group and return to work? These questions were asked many times. Would the effects of the support group wear off? Does the euphoria fade? How do you carry what you learned to an unsuspecting workplace where others have not shared your experience? I am not in a position to guess or guage reentry for the other members of my team because my workplace is kind of quiet. There's just me and Judy, and we achieved shared vision a long time ago. Well, maybe you better ask her about that. But I am concerned about the persistence of the effects of BootCamp in a more typical workplace. You learn the equation TEAM=SOFTWARE, which means that you need an effective team to build effective software (which in this context means any kind of intellectual property). At BootCamp you learn how to be a member of an effective team. How can you apply that knowledge in an environment in which not everyone understands the concept? I think that you can, but I do not know how.

The saddest part of reentry is the feeling that you have left your family behind. I formed closer relationships with some team and staff members than with others, but every one of them left with me fond and enduring memories. During the week, I did not bother to learn anyone's last name. Last names weren't necessary at BootCamp as they often are in business. As I walked down the parking lot to my rental car on Friday afternoon, I reflected on that anomaly and thought about one final joke for the team, which I tell them now. My friends, it is indeed possible to love someone whose last name you do not know yet have that love last longer than one night, be legal, and not have any money change hands. No gongs, please.

An airport is a good staging area for reentry. There is a lot of warmth and affection as people greet and say goodbye to one another. Other people, traveling alone and without friends or family to see them off or greet them, are coolly indifferent to their surroundings and their fellow travelers. Such a mixed environment reminds one of the comfort of the support group and at the same time prepares one for the realities of the cold, cold world.

I flew the red-eye back to Florida, slept all day, and went out Saturday night to face my first nonsimulated team situation -- a jazz quintet playing to a concert audience. Hardly a software product, but a team effort nonetheless, and one that definitely requires shared vision. My fellow musicians were unaware of where I had been that week, and I am not sure I could have explained it, had they asked. As we played the concert, I found myself listening to the others more closely than I did before and playing accompaniments more sympathetic to their improvised solo interpretations. When soloing myself, I felt a freedom that allowed me to form phrases, voicings, and passages that are outside my usual envelope of expression. Subtle differences to be sure, but real ones, nonetheless. If this report sounds like the effect that many jazz musicians attribute to drugs, know that the experience was real, not merely conjured from the perspective of some artificially altered reality. How can I be sure? Well, in the first place, I wasn't on anything. In the second, when the performance was over and we were packing up, one of the musicians strolled over and casually asked me, "You been practicing?"

DDJ