I want to call your attention to a new body of work with the potential to change much of what we create and how we create it in the software industry. First, however, I need to offer the following qualifier: I am not a party to this work, have no way to profit from it, and have only a distant acquaintance with the people who have pioneered it.
Whenever you enroll yourself in a group effort—a software development project, for example—you are tacitly agreeing to be bound by certain rules governing interaction within the group. The rules represent a protocol establishing such things as who may speak when and on what subject, what attitudes are out of bounds, how much frivolity is acceptable, and how much deference needs to be paid to certain managers and senior members, as well as to certain key issues.
The rules of the protocol are usually informal, unwritten, implicit, and unexamined. If you believe (as I do) that the quality of team interaction is more important to an endeavor’s ultimate success than any other factor, then failing to examine the interaction protocol should be of concern to you. We all know when a team is in or out of the groove, but what courses of action are available for optimizing this most essential characteristic of software development?
The Core
Beginning in the mid-1990s, the husband-and-wife team of Jim and Michele McCarthy and their colleagues at McCarthy TeamworX (www.mccarthy-tech.com) began developing an explicit interaction protocol they call The Core. At the heart of The Core are a few dozen interaction patterns (some healthy, others dangerous) and a set of formulas to help the team achieve an advantageous response to each pattern. These formulas, or Core Protocols, are quick ceremonies team members conduct to mark certain opportune moments in the work.
The beginning of a group work session or meeting is such a moment. Usually the participants begin with light banter, then settle into whatever focus is dictated by the designated leader. The focus may be detailed and prolonged or intermittent; it may drift or lose out entirely to competing threads and concerns. Maintaining this focus depends on the skills of the leader. Since this same leader also defined the focus in the first place, success or failure of the interaction is almost entirely in the leader’s hands.
Instead of such an unstructured approach, The Core proposes the meeting begin with a Check In ceremony. The Check In is a loosely scripted formula by which participants bind themselves to the purpose of the interaction. It gives them the opportunity to mention something about the state of their emotions, as prompted by the interaction. The group responds to each person’s Check In by saying: "Welcome." The revelations of Check In are, by the etiquette of protocol, out of bounds in the discussion that follows. At any point, the Check Out protocol allows members to remove themselves in a respectful way from the interaction. The Pass protocol enables them to remain but be passive.
Who Needs It?
My first response upon learning about The Core Protocols was to wonder who would really need more formality in the workplace. I like the informal give and take that marks a healthy workplace and appreciate the way such bantering can build informal guidelines for the work that follows. I sensed the Check In might feel artificial, even "cheesy," to use the McCarthys’ own term for it. However, as I explored the idea more deeply—reading their book Software for Your Head [1]—I began to feel otherwise. I found myself becoming a convert.
I have participated in far too many meetings where the bantering phase was delightful and the rest of the meeting totally frustrating. Meetings are only part of the frustration endemic in software engineering work. Most of this frustration is interaction-related. We can do better.
Does The Core represent a crucial advance toward better software development? I’m clueless. But I’m fairly certain it is a worthwhile attempt to deal with the essence of the work of software development.
Invest an Hour
The Core is a bold undertaking. I’m not willing to say (yet) that it is entirely successful. However, you need to know about it, and you need to track down a copy of the McCarthys’ enlightening book. Reading it will change your practice. Whether or not you and your organization adopt The Core Protocols, they will affect you.
If you had to choose between a project in which every task is performed in an ideal way or one in which team interactions are optimized, you would probably opt for optimization. Yet software developers agonize endlessly about process (how stuff gets done) and not at all about interaction. The McCarthys offer a fresh voice and an exciting new direction for you to consider.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment