I originally wrote this in 2012, a few years after discovering the work of Pierluigi Pugliese, who led me to the work of Jim and Michele McCarthy. It's merely an introductory reference for anyone unfamiliar with the term "agile" and its application to both software deveIopment and team coaching. Having written it, I then promptly filed it away and forgot about it until reminded today by a tweet from Christina Wodtke. Many thanks to all of them.
Agile Software Development
"Lightweight" software development methods evolved in the mid-1990s as a reaction against "heavyweight" methods, which were criticized as overly regulated, regimented, micromanaged and inflexible. In February 2001, 17 developers met in Utah and drafted the Manifesto for Agile Software Development, which clarified these methods:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
That is, while there is value in the items on the right, we value the items on the left more.
Principles underlying the Agile Manifesto include:
- Welcome changing requirements, even late in development.
- Sustainable development, able to maintain a constant pace.
- Face-to-face conversation is the best form of communication (co-location).
- Projects are built around motivated individuals, who should be trusted.
- Simplicity--the art of maximizing the amount of work not done--is essential.
- Self-organizing teams.
- Regular adaptation to changing circumstances.
Agile Coaching
Agile development methods require intensive collaboration among team members. A set of specific interpersonal techniques have been developed to support effective collaboration, and "agile coaching" is the process of training team members in these techniques and helping teams implement them. Some agile coaches are:
Pierluigi Pugliese (@p_pugliese)
Rachel Davies (@rachelcdavies)
Jim and Michele McCarthy (@michmccarthy)
The Core Protocols
In particular, Jim and Michel McCarthy have developed The Core Protocols, a set of interpersonal techniques that support effective collaboration within agile teams:
The Core Commitments
- I commit to engage when present.
- To know and disclose what I want, what I think, and what I feel.
- To always seek effective help.
- To decline to offer and refuse to accept incoherent emotional transmissions.
- When I have or hear a better idea than the currently prevailing idea, I will immediately either propose it for decisive acceptance or rejection, and/or explicitly seek its improvement.
- I will personally support the best idea regardless of its source, however much I hope an even better idea may later arise, and when I have no superior alternative idea.
- I will seek to perceive more than I seek to be perceived.
- I will use teams, especially when undertaking difficult tasks.
- I will speak always and only when I believe it will improve the general results/effort ratio.
- I will offer and accept only rational, results-oriented behavior and communication.
- I will disengage from less productive situations when I cannot keep these commitments or when it is more important that I engage elsewhere.
- I will do now what must be done eventually and can effectively be done now.
- I will seek to move forward toward a particular goal, by biasing my behavior toward action.
- I will use the Core Protocols (or better) when applicable.
- I will offer and accept timely and proper use of the Protocol Check protocol without prejudice.
- I will neither harm—nor tolerate the harming of—anyone for his or her fidelity to these commitments.
- I will never do anything dumb on purpose.
The Core Protocols
- Pass (Unpass)
- Check In
- Check Out
- Ask For Help
- Protocol Check
- Intention Check
- Decider
- Resolution
- Personal Alignment
- Investigate
Example:
Check In: Use Check In to begin meetings or anytime an individual or group Check In would add more value to the current team interactions.
Steps
Speaker says "I feel [one or more of MAD, SAD, GLAD, AFRAID]." Speaker may provide a brief explanation. Or if others have already checked in, the speaker may say "I pass." (See the Pass protocol.) Speaker says "I’m in." This signifies that Speaker intends to behave according to the Core Commitments. Listeners respond, "Welcome."
Commitments
State feelings without qualification. State feelings only as they pertain to yourself. Be silent during another's Check In. Do not refer to another's Check In disclosures without explicitly granted permission from him or her.
Notes
In the context of the Core Protocols, all emotions are expressed through combinations of MAD, SAD, GLAD, or AFRAID. For example, “excited” may be a combination of GLAD and AFRAID. Check In as deeply as possible. Checking in with two or more emotions is the norm. The depth of a group's Check In translates directly to the quality of the group’s results.
Do not do anything to diminish your emotional state. Do not describe yourself as a "little" mad, sad, glad, or afraid or say "I’m mad, but I’m still glad."
Except in large groups, if more than one person checks in, it is recommended that all do so.
HAPPY may be substituted for GLAD, and SCARED may be substituted for AFRAID.
(The remaining protocols are discussed at length on Jim and Michele McCarthy's site.)
Photo by Paul Sableman.
