Thank you again to Jeff Barschaw, the other agile-RTP organizers, and agile-RTP members!

I came across some new words reading Joe Little’s blog entry Two Cheer’s for the Nokia Test. In the post Joe says: “Why do I like it? I think it is a simple way to set some sort of lower boundary on Agile (Scrum) and it tends to make two problems more visible: Cowboy Agile on one side and Agilefall (aka Wagile) on the other side. Cowboy Agile is where you are doing stuff you are making up on the fly (mainly not doing things you personally don’t want to do). Agilefall is where you are doing Waterfall (or mostly waterfall) and calling it Agile (or Scrum).” This started me thinking about some curious things I’ve noticed when looking at job descriptions for ScrumMasters.

I suggest you can determine if someone is doing Wagile or Agilefall based on language. If you find command and control agile in the description, I propose you’ll find an organization interested in Wagile/Agilefall. I offer the following examples.
From a job posting on Dice.com
Responsibilities

• Keeping the project on time, using Microsoft project.
• Setting team status meetings, track milestones, drive project.
• Being responsible for driving the team and managing them to hit the projects time lines.
• Leading scrum meetings
• There will be 4 – 6 people on a team

This was the first example I noticed. It’s probably not the first one ever, but the mental models exposed grabbed my attention.

• Projects being kept on time using Microsoft Project?
• Drive the project?
• Driving the team to hit project time lines? (Does there seem to be a lot of driving going on?)

I was so amazed by this mashup of agile and command/control I didn’t have the presence of mind to apply for the position.

Posted on the Scrum development email list

We are looking for a highly motivated Technical Project Manager eager to participate in the web2.0 world of user generated content, new media, hosted services and widgets. The successful candidate will be responsible for driving technical project management initiatives.

Responsibilities

• Be comfortable acting in a Scrum Master role to facilitate the development process and ensure timely delivery of work products across a variety of product teams.
• Identify and remove roadblocks for teams; shield teams from external interferences; work with the Product Owner(s) to maximize ROI; work with the Product and Development teams to ensure goals and backlog items are addressed.
• Help ensure that technical projects are delivered on time by managing the project schedule, mitigating risks as they arise and escalating issues as appropriate.
• Formulate and work to define technical scope and objectives of the project.
• Communicate project status to management and stakeholders.
• Work with development and product teams to define project schedule and iterative deliverables.
• Manage client expectations for projects to ensure ownership and success.
• Assist in the development of project budgets, capital expenditures, requirements or other cost estimates related to a project.
• Report to management, clients and others on the status of project deliverables and milestones.
• Responsible for combining successful software development process experience with agility, effective collaboration, facilitation, leadership and coaching skills.
• Responsible for advising and coaching the development team to form empowered teams.
• Manage project schedules in Microsoft Project and simple spreadsheets for backlogs.

Qualifications include:

• 3+ years Project Management experience
• Ability to work on multiple projects at once
• Proficient in Agile Development and strong experience with Scrum Methodology.
• Qualified candidates should have experience in all aspects of software development life cycles, with an emphasis on Agile methodologies.
• Scrum master certification a plus (Desired)
• Formal project management training and/or certification preferred.
• Fluency with Project Management Tools.
• Strong, attentive listening skills with ability to work in a fast-paced environment.
• Proficiency in Microsoft Project, Excel, PowerPoint, Visio and Word required.
• Self-motivated, flexible and ability to multi-task and handle concurrent projects.
• Ability to influence and collaborate with all levels of technical and product business partners.
• Excellent interpersonal and communication (verbal and written) skills.
• The successful applicant will be a creative problem solver, a self motivator, posses a can do and attitude, positive mentoring skills and accomplishments, and demonstrate career building self improvement behaviors.

I considered not including the entire post (I did remove the company information) but felt to be fair I should include it all. Some parts of this don’t sound too bad. For example:

• Responsible for advising and coaching the development team to form empowered teams. Sounds reasonably agile oriented.

But most of the responsibilities sound command and control not agile. And what’s up with all this driving? “The successful candidate will be responsible for driving technical project management initiatives.”

About this time I started to wonder if it was me. When I read the responsibilities, they make sense. These items need to be handled by someone somewhere at some time during the project. But the way the responsibilities are worded to me indicate a non-agile mind set in spite of:

• Responsible for advising and coaching the development team to form empowered teams.
• Proficient in Agile Development and strong experience with Scrum Methodology.

I’d like to say these two examples are unique in the recruiting business. Unfortunately they’re not. You can find similar descriptions on just about any job board that caters to software development. I was going to quit with these examples, but I felt driven to find an example of cowboy agile. Alas, I didn’t have to drive very far.

Also from the Scrum development email list

[Some company] is looking for a Certified Scrum Master-Project Manager for a 2 month plus contract position for a client in [a city]. This project starts almost immediately and has a go-live date of June 1 [sic] with a project completion date of June 30. This would be our client’s first time using Scrum so some training and mentoring of the team will be needed. At the end of the project, an evaluation of how Scrum could continue to be used as well as recommended in the next steps would be required.

There are about 10 people on the team. Other than training and mentoring, this person will be expected to be the project manager. They don’t need to be a subject matter expert, just someone experienced in the Scrum methodologies of running a project. The training could just be a formal one-day training session at the beginning of the project and then just kind of on-going during the project.

Here the rules have changed. There are no rules. Am I the only person who wonders why a company with a time critical project (it goes live the day after scheduled completion) wants to shift to a new development method? And a lullaby word keeps being repeated.

• just someone experienced in the Scrum methodologies
• just be a formal one-day training session
• just kind of on-going during the project

If you didn’t read Lullaby Language I recommend doing so now.

Crossed Goals

I decided to learn more. Maybe if I could talk with someone I could understand better what they were looking for, so I replied to one of the above. I received a nice email from the person which said they’d have to talk with the account manager and get back with me, which they did. The reply was no more illuminating than the original post. After a couple emails back and forth I gave up. It seemed the recruiting company needed a body to fill a slot regardless of how it would affect the client’s outcome.

Truth in thinking:

1. It’s hazardous to generalize from a single data point.
2. These are my perceptions. I could be wrong.
3. Just because something doesn’t work for me, doesn’t mean it won’t work for someone else.

So, it is me? Or do others of you see agile being accepted as main stream verbiage while the main stream continues to do business as always? Let me know.

¹Tools For Critical Thinking, page 5

Bad Matters Worse

The bigger and more complex object we try to describe, the more problems we have accurately doing so. So what happens when we try to describe something that doesn’t exist using words that don’t really exist? Sort of a meta-non-existence if you will.

For example, how about the word “software”? What comes to mind? I can’t show you a pound of software. I can’t hear running software like I can a running engine. I can’t feel software like the resistance of the keys as I type this sentence. About all software can be is mind stuff.

Since we’re using mind stuff (words) to describe mind stuff (software), can we expect to have anything but confusion?

Sliding Down the Slippery Slope

But that doesn’t keep us from trying. So we borrow words from other activities and use them. Words like “software engineering”. Mary Shaw’s original paper is titled “Prospects for an Engineering Discipline of Software” but somehow the “Prospects” got lost, and software engineering/engineers is/are everywhere.

The difficulty arises from the mental image created with the word engineering. Engineering disciplines have centuries of use, most prior to the mathematical models and physical understanding we now have. Engineers use standard repeatable techniques to build real world objects with specified characteristics in predictable time frames. If the time frame needs to change, it’s because of phenomena visible to all (such as it rained for 40 days and we can’t build while it’s raining).

This same mental image can’t apply to creating software since the field:

• is still young (less than 100 years).
• we’re still learning how to do what we do.
• there is no physical basis.

but we use it anyway.

Since we have the engineer mental image, it naturally follows that software projects should be managed using the same techniques as other engineering disciplines creating the next mental image, software project management. And how well has this worked? Take a quick peek at Kelly Waters’ post on Most IT projects fail. It doesn’t look good from here.

So Why Don’t We Change?

The first reason we don’t change is mind share. We have organizations like the Project Management Institute and the Software Engineering Institute proscribing how Things Should Be Done, and certifying those who pass certain criteria as PMP® or a certain CMMI® level. Disclaimer I am not anti PMI or SEI. All things have their place. But we’re dealing with meta-mind-stuff and management often confuses certification with both the ability to deliver the project and suitability of the certification to the actual problem at hand.

Another reason we don’t change involves inertia. In this case I compute inertia as:

inertia = mind share * time;

The equation’s time component involves how long we’ve thought this way, and a second order effect on mind share as people who believe this way get promoted to positions of management, then upper management.

The third model lock in involves cognitive dissonance. Data says the way we current run software projects isn’t working. But mind share tells us this is the way to run software projects. Common ways to resolve the cognitive dissonance include:

• Admitting it didn’t work, but we’ll try harder next time.
• Ignoring the project failure data (could this be why we don’t do a good job with metrics?).
• Chastising those lazy, incompetent programmers.
• (insert your favorite here).

Perhaps the greatest barrier to change revolves around the question “Who loses?” Change always comes from below. No one dealt four aces asks for a re-deal. Anonymous.

Guiding the Runaway Train

We need to be aware and accept that we’re working with the wrong analogy or metaphor. Software involves some aspects of engineering, but it also involves aspects of art. Rather than latch onto an existing mental model, we need to create a new one for dealing with meta-mind-stuff. We start doing this by changing the words we use to describe what we do, why we do it, and for whom we do it. The current counter position to “Command and Control” project management is “Agile”. Unfortunately this creates dichotomous thinking when we’re really dealing with a continuous spectrum of management options.

But what I’ve heard, read, and experienced, Agile (hereby defined by me for the rest of this entry as incremental/iterative software development) has a better chance of working since it uses a different management model. Rather than working with single pass logic, agile methods advocate breaking a project in several pieces, completing each piece in a fixed period of time. This would change a single 12 month project into 12 one month projects. This provides the following advantages:

• The customer gets value every month, starting with the most valuable parts first.
• The team can review and learn from the previous month’s work prior to starting the current month’s work.
• Plans can be adjusted monthly as new information becomes available.
• The person in charge (customer, product owner, whatever name you like) can see how the project progresses.

The section “Loops All The Way Down” in A Multi-use Model contains a simplified model depicting this. You could expand the Daily Standup/Team combination into feedback loops as well, one for each team member. The loops center around:

• What did I do yesterday? (feedback)
• What’s blocking me? (environmental information)
• What will I do today? (set point for tomorrow’s stand up)

This helps answer everyone’s primary concern: What’s In It For Me (WIIFM)?

• Developers can focus on immediate tangible results.
• Customers know every iteration how well the team understood what the customer wanted.
• The person in charge has progress visibility unparalleled in Command and Control environments.

The words we choose to use when we propose changing will determine how successfully we create the new software development reality.

“Why doesn’t my manager listen when I explain the details?”

“Why doesn’t the developer just give me what I ask for?”

If you’ve ever heard these complaints—or made them–you’re not alone.  Questions like these are a symptom of a communication disconnect. Communication disconnects happen every day a variety of reasons. Three common reasons for disconnects are:

• Where we get information
• How we store and “re”present that information
• What we do with what we know.

Getting Information

Information exists in two primary places; outside us, and inside us. Some people tend to focus on the “out there information”, what they’ve seen, heard or touched. They seek specific concrete and factual experiences. You could call them “sensors” since they get information through their five senses..

Others find the information “inside” based on their experience, knowledge, and insights. With minimal external influence, these people dive inside themselves, and start looking for possibilities, meanings, relationships, and patterns. They’re more interested in “what does it mean” than “what”. These people could be called “intuitors”, since their intuition guides their actions, rather than data.

The disconnect happens when “sensors” and “intuitors” try to share information. A sensor asks a question expecting to get specific data points, and instead gets a rambling (to the “sensor”) discussion of patterns and possibilities. Instead of a general idea and pattern of information, the intuitor hears a flood of boring minutia leaving the requestor wondering what the other is blathering about.

To reconnect, a sensor can ask “what have you seen, heard or experienced that leads you to this conclusion?” Intuitors could ask “what does all this data mean?”  Even better is to know yourself – whether you’re an intuitor or sensor, and what the other person is. This enables you to respond to the other person’s style.

You can practice being the other type. If you tend towards “intuiting”, try to notice several “out there” things every day. Carry with a small notepad at all times and jot down your observations, for example, a dirty brown-and-white dog sleeping in the street; a  programming error that prints out the message, ‘RANK ERROR,’ then crashes Windows; a tall young woman in the next cubicle wearing Jovan perfume, making the noise of sharpening a gross of pencils.

Sensors can periodically pause and ask questions about the data in front of them. Is Jack’s current coding difficulty related to Jill being on vacation? It looks like progress is slowing, why? The Rule of Three encourages having at least three possible choices before selecting one. Use your imagination and explore beyond the first obvious answer.

Storing and “re”presenting Information

We store information internally in our mind as sights, sounds, feelings, or abstract concepts. The way we store information is called our representational (rep) system, since that is how we “re”present our experiences.

Take a moment and think back to a particularly enjoyable experience you’ve had a work. What came to mind? Did you see your teammates, maybe a particularly gnarly chunk of code you to which you finally saw the answer? Were there sounds of laughter and joking? Maybe you recalled feelings of happiness?

If you primarily saw the enjoyable experience, you use a visual rep system. Recalling memories and hearing sounds involves the auditory rep system. Primarily noticing the feelings (touching) means the kinesthetic rep system is being used. Remembering abstract concepts (the lack of visual, auditory, or kinesthetic descriptions) indicates a preference for the digital rep system.

Like most preferences, no rep system is better than another. They’re simply the way the way we tend to store and recall our experiences. We can (and usually do) use all of the rep systems, but most people have a preferred way of representing what’s in their mind.

The disconnect happens when interactions become intense, and the rep systems get crossed. Suppose you say, “That doesn’t sound right to me”, and I respond with “I can see that.” We just crossed rep system boundaries. You now have to translate my visual response into its correct translation in your auditory processing. To stay connected, I could have said, “Yes, I hear what you’re saying.”

To reconnect, listen for sensory words. When words appear like bright, clear, display, see, conceal, the speaker has a visual orientation. When you hear words like asked, talk, explain, complain, harmonize the speaker has overtones of a hearing orientation.  Feeling words such as touch, soft, smooth, pressure or excitement slipping into the conversation push towards a kinesthetic, or touch preference. When you become aware of words like believe, consider, decide, know, learn, process, perceive, the speaker is using the digital rep system.

To improve communicating, try to match the sensory mode of the other person. That way they won’t need to translate words from one sensory mode into another. A good time to practice this is when you reply to email. You can scan the incoming message for sensory words, and match the rep system in your reply.

Mind Reading

“I know what you’re thinking.” You’re thinking this is a lot of new stuff, and feeling overwhelmed with the ways communication disconnects happen. Which brings us to another disconnect called “mind reading”. Mind reading works on three basic (and faulty) assumptions:

• You take in the same information I do.
• You process this information as I would.
• You come to the same conclusions and decide to behave exactly as I do.

In short, I project my reality onto you, and tell you what you’re experiencing.

The disconnect happens when we mind read, and then take action without confirming what the other person really thinks. This creates misaligned goals, actions, and often hard feelings.

A developer made a decision that I thought should have been made by the customer. When I asked the developer if he should ask the customer, he said (and you can’t make up stuff like this), “I’ve been doing this for 20 years. I know what he wants better than he does.”

You can avoid this disconnect by not mind reading. Rather than assuming you know the answers, ask questions. I’ve had people become irritated when I asked clarifying questions in order to avoid mind reading. If you find someone mind reading you, you might ask them “How specifically do you know how I feel (think, whatever)?” or “What did you see or hear that leads you to that?”

Calibrating Communications

When I work with a client, I first try to understand where they get information. Do they look for data (sensors), or rather hear about how this fits in the grand scheme of things (intuitior)? Sometimes it’s not an either/or. Perhaps they need the fit in the grand scheme with supporting data.

When I supply the requested information, I try to match the requestor’s rep system. This saves time and effort since they don’t have to translate my meaning.

Lastly, to avoid mind reading, I ask how the communication went for them. Did they get what they needed, in the format they could use? If not, I have new information that allows me to change what I’m doing.  If they got what they needed, I’ve avoided the communication disconnects.

Have you ever read something that bothered you, but couldn’t put your finger on exactly why? I found myself in that position after I read George Dinwiddie’s recent blog entry about Blocking.

Scott Ambler’s “blocking” doesn’t bother me. I don’t see that giving management the information they need, in the format they need it, a problem. If doing this allows the team to continue working on their tasks providing value (via working software) to the clients, I’m all for it. It sounds to me like part of a Scrum Master’s job: remove impediments.

The discussion on PERT intrigued me, but it turned out to be a red herring. PERT doesn’t manage a project. Neither does a burn down chart. People manage projects. It might be a product owner and a self-organized team. Maybe a PMP project manager. But it’s always people managing what gets done. At the abstract level, a PERT chart and product release schedule are more alike than different; a list of what needs to be done, and when we think we might finish.

I could argue with George’s comments about how pretending to do something but not actually doing it is a bad thing, or that the communications fail when we quite trying. But I’d be arguing just because I like arguing with George. I learn things when I do.

All Together Now

Finally I saw what bothered me, another example of insufficient views. The team has a view of what they need. Management has a view of what they need. Both sides have their view point. But because of some communication disconnect, my view and your view never become our view. The communication had reduced to a management/team, us/them mentality. In reality there is no management without a team, and no team without management. Like “mind” and “body” one needs the other to exist.

Remember the Prime Directive if you have problems finding “our view”. They’re doing the best they can, as are you. While it may be difficult to find “our view”, it’s worth the effort. You’ll learn something, they’ll learn something, and you’ll avoid the pitfalls of “apparent compliance”.

What’s Your View on this? Add a comment, or sent me an e-mail.

I’ve been reading some interesting emails concerning names in an Scrum environment. Backlog in particular seems to generate energy.

Several valid points for change have been made. Backlog felt negative to one team, and they wanted to use a positive term. Another participant mentioned that “backlog” was difficult to translate into his language. Yet another argued that Agile is more about what you DO, than what you name what you’re doing. I think these points have validity.

So what’s the problem?

Take a step back and ask, “What is the purpose of language?” What did you come up with?

For me, the purpose of language is to get the thoughts out of your head into my head, and vice versa. This has several benefits:

1. We can learn from each other’s experiences.
2. We can share (and help create) knowledge.
3. We can co-create a co-reality.

What it Looks Like

We interact with the real world, and through the processes of abstracting (extracting sensory data) and abstraction (converting the sensory data in to words, thoughts, and feelings). Words (hopefully) represent some object in the real world. When we interact with another person, it looks like:

Communicaton Model

The explanation is contained in Getting to Language.

The Problem Arises

As Kelly Waters points out when you choose to use different words, translation trouble occurs. George Dinwiddie and I recently had a discussion about a Scrum Project. Since we share a common Scrum vocabulary, we discussed the project owner, product backlog and sprints with no explanations. We didn’t have to say “OK, by product owner, I mean the person who ….”.

What NOT to Do!

• I doubt I’d whip out the diagram. If pushed for why common words are important, I’d use the Satir Interaction Model
• I wouldn’t say they’re wrong. If we argue, the team will become more entreched. And I don’t believe the team is wrong.
• I would avoid discussions about “The One True Way”. Agile (and Scrum) are about providing working software and business value. I’d prefer to use the same words other teams use (especially if they mean the same), but that’s not the major goal.

So What to Do?

To resolve the “backlog” seems negative to the team issue and keep the same word for “backlog” (which is of course “backlog”), I’d try the following:

• Acknowledge the feeling that “backlog” seems negative. It’s how the team (or some portion of the team) feels.
• Explore with the team WHY they think “backlog” is something negative. Are all backlogs negative? Is it possible for some backlogs to be positive? Could it be that backlog is both positive and negative?
• Based on the exploration, I’d try to get an experiment approved where we used “backlog” for a set number of sprints, and then revisit the issue. This is the “Trial Run” Pattern from Fearless Change.

I suspect that after three sprints, the concern about “backlog” being negative will disappear being replaced by other concerns about delivering business value via working software.

“Why doesn’t the developer just give me what I ask for?”

These questions popped out during the Tutorial at this year’s AYE Conference. Realizing the energy, Steve and I held an impromptu discussion on the topic.

What came out of the discussion? Both groups were “mind reading”. Guessing what the other person wanted, and how they wanted it.

When I work with a new client, I follow these three steps to remove mind reading to improve my communication with the client.

1. I ask them what they want. Do they want a summary? “The ship is sinking.” Do they want a summary and action items? “The ship is sinking. If we can isolate the compromised compartments, we may be able to stay afloat.” Do they want details so they can form their own conclusions? “We just hit an iceberg. The forward port compartments 1 – 4 have been compromised and are taking on water.” Even when I summarize, I have detailed information available if asked for it.

2. I ask them how they’d like to receive the information. Sometimes people want to hear the information. Others prefer something written; email, report, spreadsheet, whatever. When you give them information in the requested format, you’re respecting their personality preferences.

3. After the first report, I ask if the information I gave them, and how I presented the information worked for them. This step gives me information on:

- Did I understand their request for information?
- Was I able to meet the request?

Following these steps simplifies my task of sharing information. It also simplifies management’s job of repackaging the information for others to view and use.

Your diagram is interesting, at least two ways.

First, when you’re not doing email (or phone) there are more “channels” than simply “language”. Indeed, in your example you two were operating with a particularly thin communication mechanism. One of the countermeasures, I think, is having a pile of communication channels going on at once, then you can compare between.

I suspect that the “Satir interaction model” is actually hanging out attached to at least “Experience of Experience” and “Sensory Experience.” We have attachments at these levels of experience as well, and make meaning that we can sometimes verbalize, but is pre-verbal in the meaning. “Bad thing” as an emotional, visceral response does, indeed exist in a way that the words “bad thing” don’t necessarily capture, and the words are after the fact, in addition to the words and word processes generating experience.

I suspect that having the additional processes going on has a an effect similar to the family of flight control systems in a space shuttle – richer, and thus more robust, and more interesting in what it generates.

Comments? Send me a note.

He called recently wondering why the software we’d developed quit working, and now wouldn’t compile. We spent a half hour discussing this line, that line, adding lines, commenting lines, and getting no where. Since my code compiled, I finally suggested he send me HIS copy of the code. The problem turned out to be a cross communication involving 4 lines of code (located in two different modules).

Somehow, for some reason, as we looked at the code, neither of us put the descriptions of what we saw together with the results Albert described. It wasn’t until I had his code that I found the difficulty. And why was that?

We were congruently communicating. We both wanted the same goal, but the longer we talked about the problem, the more frustrating it became. The Satir Interaction Model wasn’t helping. It turned out that the problem didn’t exist at the language level. It existed in the process of GETTING TO the language level.

Yet Another Model (YAM)

Here’s a model that shows one way of getting from the REAL WORLD, to the language level. I lifted this from Maps, Models, and the Structure of Reality.

Modeling Levels

Like all models, this model deletes, generalizes, and distorts information. I’ll probably blog more about this someday.

The real question we need to consider is: “Does this model provide a useful map of the territory?” To me it does. It shows (some of the) transforms we make between the “World Out There”, finally ending in language. Just so you’re not surprised, each logical level involves its own model, and moving from one logical level to the next one or more processes.

When we add the bi-directional (simplified) Satir Interaction Model, we get a more complete understanding of the problem Albert and I experienced.

Communicaton Model

In our case, the World At Large differed. When moving from his World At Large, Albert deleted information (and we all do). Even though I tried, I couldn’t “language” down his modeling path to understand his World At Large. Once I could see his World At Large, finding the compile problem became much easier. Our worlds were the same.

So the next time you’re talking with someone, and you see the conversation isn’t working, remember:

Even though you’re talking the same language, how you got to the language makes the meaning of the language.

Human systems such as companies, departments, teams, and even individuals experience the same environment boundary problem as they interact with customers, other departments, other teams and each other. The fact that these interfaces continuously change means problems can always arise.

Since information flow is one defining characteristic of a complex adaptive system, having a tool to help untangle interactions run amok will be immensely useful.

The Satir Interaction Model

A simplified version of the Satir Interaction Model looks like

Willem has a better diagram showing how my response becomes your intake. (Go ahead and read the post. I mention it again.)

Willem also mentions speeding through the Interaction Model results in reactions, not responses. And there may be a natural reason for zipping through the steps: your Myers-Briggs Temperament. Jerry Weinberg mentions in QSM 3: Congruent Action

NTs & NFs should use the Rule of Three since they don’t usually actually perform the intake step.

Words Create Meaning in Other People

And we don’t get to choose what that meaning is, they do. We can say something innocuous (to us) and the other person will assign some meaning, significance, and respond in a way that totally surprises us. Jerry said “snow” at a client’s site, and a woman attacked him. They did resolve the issue (using here-now-us).

Rewinding and going over the conversation, preferably with the other person illuminates what happened, when, and where. This can increase understanding and trust.

Debugging

When using the Satir Interaction Model for debugging, an expanded version1,2 can be used:

1. Intake – sensory input, what you see or hear.
2. Meaning – how you interpret what you see or hear.
3. Feelings – what feelings you have about the meaning.
4. Feelings about those Feelings
5. Defenses – projecting, denial, ignoring
6. Rules for commenting – often learned as children at home or church
7. Response – the result (outcome) of all the above

And as Willem notes there needs to be a level of trust and openness before this will work with two people. While not as effective, reflection and discussion with another person may shed light on the interaction.

In Real Time

In spite of all the steps, we go through the entire model in fractions of a second. If you’re engaged in a downward spiraling conversation (and eventually you’ll start to notice this earlier and earlier) you may consider doing the following:

• Ask yourself “What can I do to change how this interaction is happening?”
• Slow things down. Breathe deeply and hold it for a few seconds when it’s your turn to speak.
• Use the rule of three to check your input (especially if you’re intuitive).
• Check your feelings to see if you’re responding congruently.
• Admit to the other person you’re confused by the interaction and ask if they’d like to go “meta” and have a discussion about the discussion.

1 The Satir Model: Family Therapy and Beyond, 1991 Science & Behavior Books, Inc. ISBN 8314-0078-1, Chapter 6
2 Becoming A Technical Leader Chapter 10