Bootcamp for software designers

[Ace Pace]

The Link

"What? You want me to tell you what to do, like some big boss?" Jim McCarthy, software management guru, Microsoft alum, and master-sergeant at the McCarthy TeamworX Software Development BootCamp, stares coolly at October's batch of inductees.

It's a Sunday evening, less than an hour into the five-day course, and the class is floundering. They've come a considerable distance six recruits from a Minneapolis medical software firm, two from a Connecticut business software company, and one Bay Area games programmer and paid $5,000 apiece to learn to do what few in this industry can do consistently: ship quality software on time.

But everything about the camp seems to be jarringly at odds with the high-tech, high-stakes, high-intensity world of software -- starting with the rustic setting, a Lutheran retreat center just east of Seattle. There are no computers. No T1 lines. Not even overhead presentations. Worst of all, when the students finally learn what they'll be doing for the next five days -- an unusual software project too proprietary to reveal here -- the assignment seems neither anything they know how to do nor what they signed up for.

"Could we get some more detail?" pleads Chris Holton, a blond, 28-year-old marketing director from Minneapolis. "I'm confused," confesses Sean Vikoren, a 32-year-old games programmer, his angular face showing both skepticism and irritation. "It seems to me that you've set us up, then cruelly chucked us into the abyss."

It is a cruel moment, one of several guaranteed at every TeamworX BootCamp. Tonight's class, for example, has just been weaned from management dependency: the campers will not be "rescued" or told what to do. Over the next five days inductees will unlearn much of what they've been taught about developing software. "You can't have great software without a great team," McCarthy says. "And most software teams behave like dysfunctional families."

Teaching teams how to function is McCarthy's main mission. A bearded, weary-looking 45-year-old who favors cowboy boots and loud shirts, he began writing software in 1976. He spent five years at Microsoft where he worked on various hot products and, along the way, found the secret that lets development teams produce killer software, on time, without killing the team members.

Great teams, it turns out, begin with a shared vision -- a unified, clearly articulated belief about the software they're creating. Great teams have, and are driven by, genuine passion -- a collective regard for the project as art, not "work," and a personal sense of responsibility for its completion. Moreover, great teams are not hierarchical or autocratic; they tap each member's creative potential.

Great teams are also absurdly rare -- made scarce by corporate cultures that rely on top-down management, set totally unrealistic production schedules, and solve problems simply by working very smart people for very long hours. "When people say 'hard work,' what they really mean is using individual heroics to compensate for the inefficiencies of the system," says McCarthy. "It sucks. But that's how most of us make software."

McCarthy's ideas -- presented first in lectures and, last year, in a book, "The Dynamics of Software Development," published by Microsoft Press -- have earned him a devoted following among desperate program managers. In early 1996, he, his wife, Michele Frame, his son Kevin, and five other former Microsofties -- John Rae-Grant, Jeff and Inga Beehler, Steve Skrzyniarz, and Laura Petersen -- created the TeamworX BootCamp, a living lesson. But the lessons aren't painless. Before they can enter the brave new world, students first must break from the old by plunging or being plunged into a temporary abyss of uncertainty, anxiety, and chaos.

"This is where the last group completely broke down," says McCarthy, watching the class tackle a cooperative exercise on the center's vast lawn. It's Tuesday, 2 p.m., and while the students exhibit no obvious mental trauma, they are still a bit wild-eyed. They've spent the last 40 hours in a state of fluctuating mania: organizing, arguing, deciding, and, above all, making lists: lists of optional team "visions," lists of elements within those visions, lists of techniques for creating those elements, and, finally, a list simply entitled "How to get fucking started."

Yet coherence is emerging. The diverse outfit is functioning as a single unit. Cooperation is constant. Communication styles have assumed important new dimensions. Excuses, for instance, have dwindled. Boot-campers are expected to explain how they can get something done, not why they can't. The instructors initially enforce the "no bullshit" policy, but the students quickly embrace it -- none more aggressively than the formerly skeptical Vikoren.

It's all a part of establishing a team vision -- a top priority at TeamworX BootCamps. Beyond its power to unify and motivate a team, a strong, shared vision works like a conceptual road map or, in McCarthy's computer metaphor, a set of design algorithms. Here's an easy example. A BootCamp team's shared vision might include the following elements: "This software is for beginners. Beginners prefer graphics to text. Beginners need more feedback to proceed." Once adopted, these elements, or algorithms, serve as guides for all team actions and decision.

A shared vision, in the TeamworX view, is the conceptual Holy Grail. It increases efficiency, boosts output and quality, maintains team spirit -- and requires something of a crusade to find. Getting a vision requires massive input from all team members about how and what each will contribute, and also about how a project reflects their core values, their fears, likes and dislikes.

Given the importance and complexity of vision-making, this is one of the few stages at BootCamp where TeamworX instructors will step in and offer a traditional lesson. In this case, intervention comes Monday night. Wearing their "management black hats," staffers come down hard, criticizing the team's proposed vision as "messy," and offering clear suggestions. The advice is snapped up, and, by Tuesday morning, the team has successfully "shipped" its first product: its vision.

Wednesday finds the camp again in chaos -- albeit of a happier variety. At stations around the Lutheran center, boot-campers are playing charades, making music, doing blindfolded finger-painting. "Creativity Day," as it's called, is multipurpose: stirring creative juices, catalyzing right-brain thinking, and providing a break from "the schedule."

And this class needs it. Tuesday afternoon, after shipping its vision, the group split into self-chosen teams and prepared for their first "deliverables." These are specific projects that must be completed in accordance with the vision, and integrated with those of other teams by week's end. But things got out of hand. TeamworX instructors kept piling on the assignments, quickly exceeding what a team twice the size could handle.

The students' puzzlement turned to alarm, then anger. The cry went up, "Bullshit!" -- BootCampers rebelled. They refused additional work, tossed assigned materials on the floor -- and gained, in the process, yet another critical lesson in project development: the virtue of "pushing back." The objective, says TeamworX's Michele Frame, is to destroy the notion of the infallible authority. Bosses can be totally wrong, deadlines totally unrealistic. Yet most employees feel compelled to sign on to unreasonable schedules, and to act as if they were realistic. Members of a healthy team nix unrealistic objectives -- or anything else that violates their shared vision. "These guys pushed back hard," says TeamworX's John Rae-Grant. "It was great."

Now, in the aftermath, in the midst of blindfolded painters and pantomime, the learning of the past three days seems to be coalescing. Walking down the dormitory hall, absently hefting an orange Nerf toy shaped like a human brain, of all things, Vikoren the Skeptic is now Vikoren the Believer. "How to put this into words," he says. "This is one of the most profound learning experiences I've ever had." He stops. "What I plan to do after this course is to reevaluate my life from top to bottom: where I live, what I do and how I do it."

He resumes hefting the Nerf brain and heads down the hall toward the cafeteria. It's lunch time.

And crunch time. With a Thursday night deadline to ship product, boot-campers begin the process of integration. Students are now fine-tuning -- "going for greatness."

Instructors feel compelled to bring out the black hats, however, over the critical issue of scheduling, the bane of software development. Even well-intentioned managers are apt to create meaningless timelines -- chronologies that have nothing to do with either the actual projects or the people who will do the work. Real scheduling is strictly "bottom up." In the world according to TeamworX, says McCarthy, "no item appears on the schedule if the person who has to execute it hasn't bought into it."

Schedules corrected, the teams deliver their "products" and celebrate as if they just released Windows 95. Friday morning at 9:30 AM, a bleary crew settles into the center's chapel for a closing ceremony. The mood is high, enthusiastic -- and anxious. All seem eager to take their new skills back to their real workplaces; each fears being perceived as strange. It's a standard issue. The TeamworX staff offers a variety of tips for dealing with "re-entry" issues (also known as "individual perceived weirdness")and even performs a hilarious skit showing how not to talk to your boss on the first day back. One suggestion: "Tell co-workers what you learned, not necessarily how you learned it."

At the same time, however, McCarthy pleads with students not to believe they can ever get back to "normal." "Get a handle on what is 'normal'," McCarthy says. "What you've experienced here, this is normal human behavior. It may not be common, but it s normal."

Paul Roberts (proberts79@aol.com) lives in Seattle and writes on business, technology, and workplace issues. You can visit Jim McCarthy and McCarthy TeamworX on the Web at (http://www.TeamworX.com)

Intresting, anyone know more about this?

[Mr Bean]

It's a nice idea, but we can hire a hundred Indian programmers to fling at the problem for less than it costs to put these people through this bootcamp.

Moreover programming is not a displine where boot-camp tatics work well. Much like with most engineering displines.
Build that bridge! Buuuild it faaster! To slow, drop and give me twenty!
Debug that core file!, What? Waiting on the compiling? Then give me ten laps round the building doooouble time!

Seriously... how effect can it be?

[Ace Pace]

It's a nice idea, but we can hire a hundred Indian programmers to fling at the problem for less than it costs to put these people through this bootcamp.

Moreover programming is not a displine where boot-camp tatics work well. Much like with most engineering displines.
Build that bridge! Buuuild it faaster! To slow, drop and give me twenty!
Debug that core file!, What? Waiting on the compiling? Then give me ten laps round the building doooouble time!

Seriously... how effect can it be?

If you would read the article, you would see its more on on proper design of software then any actual coding itself.

[Mr Bean]

If you would read the article, you would see its more on on proper design of software then any actual coding itself.

From what I read it's more the fact he's had un-teamworking very smart dumb people who can't work togther, and through peace, love and understanding teachs them how to remove the pole's up various people's ass.


My post was a late night random wondering on how exactly a Drill instructor would improve coding results.

[phongn]

Design is the most important part of software development; coding is the grunt work. That requires proper teamwork, and this sounds like it can help with that.