The backstory here is my exploration of different ideas relating to coaching circles, mentor groups, and other formats. As often happens when working with a concept important to our own development, the idea keeps coming up all around me. The group with Bachan is the second such group I’m leading with Agile coaches. Then, last week a coaching colleague (not an Agile coach) asked me to help her start a group coaching program for a large financial institution. Suddenly, I realized how my world was calling me into something.

What I’m wrestling with is how to choose–or perhaps better, to synthesize–from amongst different forms to guide these groups. My purpose is to share two things: my experience in coaching and organizational transformation, and my professional coach training as a relationship systems coach.

One form is the self-organized Coaching Circle. The Orlando Scrum Gathering recently held a session on this format, documented here. This form taps into the richness of community that comes from peer collectives and the power of the Community of Practice, a concept articulated by the anthropologist Etienne Wenger.

A second form is one I have personally experienced: the Mastermind group, originally articulated by Napoleon Hill. My mastermind group is a source of inspiration, intimacy, tremendous personal support, as well as accountability and challenge. It is a group that will ‘call me forth’ to my own greatness. (If you don’t have one, do yourself a favor and investigate it.)

I grew up as a clinician with case presentations in Peer Group Supervision. The learning that happens in this context can be both deep and vulnerable. Even though the center of attention seems to be the client problem you brought to the party, what is truly revealed is our own patterns, limitations, preconceptions and false beliefs, in addition to our magnificence and power.

Finally, the Mentor Group is a form I am starting to explore in a big way. It leverages one or more people with extensive experience across multiple mentees, who both benefit from the mentor and from the network of their peers.

The synthesis for me right now could be called a Coach Mentor Circle. It combine the Mentor Group with the Coach Circle, while also using a component of Peer Group Supervision. This will go on for a set number of sessions, then the group will become whatever it needs to be, perhaps a Mastermind group. I believe this is part of something trying to happen in our world. . .bringing coaching and mentoring to more people and creating community bonds and networks in the process.

By the way, there are still two slots open, so if you are interested please let me know.

The Tao of Events

Release Planning defines what users of the Way will find of value, and by when.

Release Planning may remind us of the old days, when management asked for dates (and commitments) that we could not give, or could not keep. It can be tempting to skip over Release Planning, especially for a new team. But having a view of where we are going gives us confidence, and helps us know when we have lost our way. Release Planning is not about dates (though everyone wants them), but about sequence and size. Release Planning might be best done during the first Sprint, after we have the chance to get our mind on straight as a team.

Sprints are the Way of the Team, and do not vary in length.

Sprints are the heartbeat of a Scrum Team. They provide the rhythm and backbone on which ritual can form, rituals that teams need as human systems. The Sprint cycle provides a beginning and an end, creating a familiar comfort against which to remember where we are, where we are going, and how we can do better the next time around. Over time, the Sprint may get shorter, but do not let it get longer.

Sprint Planning defines the Way for this week, and for next.

The Sprint Planning meeting begins the cycle. It says this is a new day, we can do anything, together. It lets the business customer tell their story and the team ask their questions. It gives the team their marching orders, and the Product Owner, hope for the immediate future. It is the project community’s central ritual, along with the Sprint Review. It should be adjusted to fit the community, whether with food, music or anything that connects people’s hearts.

The Daily Standup helps the team Adapt to the Way, for today.

The standup is the place where accountability within the team becomes real. Those embarasssed to ask for assistance will be stuck on the same task, day after day, while declaring ‘no impediments.’ Some will be vague when declaring what they will do today, unsure of themselves and of their support. For others, the standup is a celebration of how well they work together and how much they can conquer as a team. If everyone does not learn something during the standup, there is either a lack of real listening, or the team is talking from rote. Perhaps there is a lack of trust?

The Sprint Review helps the users of the Way Inspect what has been done in two weeks time.

We come back to inspection. The Sprint Review is for the project community–as many of them as possible–to come together and see what has been done. Real feedback is essential: the good, the bad and the controversial. Senior leaders are sometimes reluctant to attend. That is a shame. This is where the real work gets done. Perhaps they haven’t heard?

The Retrospective helps the team decide the Way forward, by Inspecting the Way that is past.

The Sprint Review is to the project community what the Retrospective is to the team: their inspection, and introspection, process for themselves. Did they get better this Sprint? Did they accomplish all they could as a team? Did they have fun and feel relaxed? Where is their cutting edge? And how can they get over it?

Following was inspired by the Tao Te Ching (Dao De Jing). I was preparing to teach a new Agile team and wanted a simple version of the rules of Scrum. I started with the Scrum Guide, which I distilled down into 15 basic rules and 53 sub-rules. The basic rules, in this Taoist-like format, are a kind of Ri (expert or master) version of Scrum. In this post are the first four rules, with comments.

The Underlying Tao

The Way is Transparent. The Way should be Inspected. What is Inspected should be Adapted to.

The basis of Scrum is that it is transparent:  to the people who pay for development, to management, to customers and users, to the team itself. Of course, this sounds good, but in fact people often hate it. It is hard to give up old ways, to be exposed in our comfy habits. So we don’t always take full advantage of transparency. We want transparency of some things, but not others.

Next, given that we have transparency, we are now in a position to inspect what actually happened. Did our plan work out? Did the change to greater detail in our stories actually make a difference? Were we able to get QA more involved this sprint?

Finally, when we see the results clearly, it is incumbent upon us to make changes, to adapt. If QA did not get more involved this sprint as we wished, what happened? How did we fail? What can we do differently? The questioning mind is an open mind. In the beginners mind there are many options, in the expert’s there are few.

The Tao of People

The Product Owner decides the ‘what’ of the Way.

With only one person making decisions on what to work on (and why), teams are able to get very clear and move very fast. With inspection, everyone  sees whether those ‘what’ decisions actually worked out. The Product Owner is likely to either love or hate this arrangement. If we know where we want to go–and are able to adapt quickly to feedback–it is wonderful to be the driver. Conversely, if our success has been due to maneuvering around accountability, this will be an unhappy path with which we will likely find fault.

The Team decides the ‘how’ and ‘how much’ of the Way.

In regards to the Product Owner’s direction, the Team decides both how to accomplish the ‘what’ and how long it will take. To do otherwise will tip the scales of power unwisely, in ways that do not reflect reality accurately. Teams feel the integrity of the process when this dictum is upheld. It conveys respect and professionalism.

The Scrum Master serves the Way, and tells others when the Way has been lost.

Ultimately, the Scrum Master must serve the Way itself. For Scrum, the Way is embodied in its rules and essence. At times, the Scrum Master may feel like a voice in the wilderness, trying to be heard above the din of deadlines and demos. But if she serves the Way truly, her voice will eventually be heard. If it is about his ego, or results, the Scrum Master will fail: himself and the Team. This is very hard for the new Scrum Master to learn. We have been trained that we must be responsible for the team’s results. Ultimately, attempting to do so will compromise our allegiance to the Way of Scrum.

I applaud Jean for having brought the issue up and agree with her on many of her points. At the same time, I also agree with some of those saying their conflict is necessary and fruitful, notably my friend Tobias and others. For what it’s worth, I wanted to offer my take.

First, conflict is beyond inevitable, it is essential for any relationship–such as teams–especially where people are trying to achieve something together. In my practice as a team coach, the lack of conflict is a signal to me that something is wrong. Perhaps there is not enough trust, communication patterns may have become toxic, people may simply not care about each other enough to risk disagreeing, or maybe there is an abusive managerial dynamic giving rise to an environment of fear.

Healthy conflict is the sign of a mature relationship, whether within a team, between business partners, or within a marriage. So, what makes for healthy conflict and why is it so important?

Let’s first examine why it’s important. Based on extensive research conducted at the University of Washington by renowned relationship expert Dr. John Gottman, positivity in relationships is the key to long term sustainability and happiness. His observation of relationships that last over time is that the ratio of positive to negative behavioral “transactions” needs to be about 5 to 1. He describes it like a bank account, where you make deposits in positive interactions and you make withdrawals with destructive interactions.

Gottman’s research led him to document a taxonomy of the most destructive types of negative interactions. They are:

1. Criticism/Blaming
2. Defensiveness
3. Contempt
4. Stonewalling

Briefly, by Criticism Gottman does not mean giving direct feedback on someone’s behavior, but rather a form of blaming where the person’s character is impugned. For instance, a tester says in a retrospective, “development just doesn’t care about quality with all the bugs they are allowing to get to us.” Not surprisingly, such Criticism can give rise to Defensiveness. A developer in the same retrospective responds, “we can’t help it, we’re under a lot of time pressure to finish all the stories.” The manager chimes in “can’t you people figure anything out! I’m sick of having to help you deal with your kindergarten name-calling. I should probably just work on getting a whole new team. Hope your resumes are up to date.” At this point, Contempt has shown up, the most dangerous of the four toxic communication styles. Meanwhile, the team sits there as the manager rants, not reacting, pretending not to even hear him. This last style Gottman calls Stonewalling.

The interconnection of these four communication patterns is clear: Criticism often leads to Defensiveness which can lead to an increase in Criticism and, eventually, to Contempt. Lots of Contempt can result in closing down or Stonewalling.

Back to Jean’s post. I believe at least part of what she is identifying is the presence of these toxic styles within the Agile community. Certainly, a fair proportion of blog posts and email list exchanges could not be described as positive interactions, and I have not infrequently felt the parties were demonstrating contempt for each other’s opinions. The cumulative affect of this can create a culture of negativity, not positivity (remember how important that is for good relationships?).  But is this negativity only a problem for the “thin skinned”?

In Gottman’s research, there was an extensive physiological component, including blood tests and biofeedback monitoring during and after arguments. As Gottman accumulated evidence about this, particularly the toxic physical affects of enduring someone else’s contempt, he made a change in the research. Gottman concluded that so much physical and emotional harm was caused during an argument involving contempt, that he decided to stop the research whenever such arguments occurred in order to act in an ethical way.

Now, back to Tobias. When some people have a “conflict,” they really do enjoy it, while respecting and potentially even having fun with their “adversary.” If team members can come from the place of curiosity, respect, playfulness and real appreciation when they debate various team issues, suddenly it does not have a negative impact at all. In fact, if taken with the right attitude, it may lead to being able to celebrate the diversity of views and perspectives inherent in relationship.

Here’s the rub: the difference between an argument that feels contemptuous and a debate that is stimulating is in the experience of the behholder, so to speak. You can only know how the other person experiences what is happening by asking them.

I would be interested in any thoughts you all have about this topic.

Cheers!