Exploration Through Example

Example-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick
191.8 167.2 186.2 183.6 184.0 183.2 184.6

Sat, 08 Oct 2005

Blaming and lecturing

Satir's models of communication, change, and communication stances are influential among those who worry about software team dynamics. I'm uneasy about them on two grounds.
  • One is that the categories they draw strike me as too big. Consider the communication stances. The model identifies three "things in the world": Self, Other, and Context. People take bad communication stances when they (try to) ignore one or more of those things. For example, a Placating person will ignore Self in favor of Other and Context.

    My difficulty is that there are so many Others and pieces of Context ready-to-hand at every moment (even if you're talking to one person about one thing) that I'm uneasy about the idea of ignoring Context or Other. That probably means ignoring a lot of the Context or Other, but the parts you don't ignore are probably awfully important. (And, as a teensy bit of a postmodernist, I'm not 100% sure it's always that useful to think of a unitary self, so even ignoring Self is maybe not such a straightforward idea.)

    Now, I expect the model has been expanded, but my informal encounters haven't shown me the elaborations. Perhaps I will at the AYE conference.

  • The other source of unease is that Satir's models are grounded in family therapy. That, it seems to me, often leads to overconcentration on the negative. Function becomes the absence of dysfunction, joy becomes the absence of frustration. One becomes "congruent" by ceasing to ignore one, two, or three of the things in the world.

    For example, in the change model crisis kicks off change. Change must push through resistance. Again, that's certainly often true (and consultants must often deal with resistance). But that's not the way all change happens. Some people like change, and others are agnostic (the change threatens nothing they particularly care about). My impression is that a lot of the elements of XP were more motivated by a harkening back to an idyllic time at Tektronix Labs than by stark necessity.

    (A preference for Satir may be a product of selection bias. Back when I was a pure testing consultant, I - like an awful lot of consultants - got called almost exclusively into companies with problems. There, the Satir model is so often appropriate that it must be easy to see dysfunctional family life everywhere. Now that I'm consulting in Agile, I more often go to companies that are doing perfectly OK and want to do better. That promotes a sunnier view of life.)

But that's not what I mainly wanted to write about. In the communication stances model, the ignoring of Other leads to Blaming behavior. If I model my own behavior that way, I'd say Blaming is not often the result. What I do more is Unstoppable Framing and Advice-Giving. It's figuring out what the problem and its context are, plus throwing out all kinds of potential solutions. That's different than Satir's Super-reasonable behavior, which is "cool, aloof, reasonable, and intellectual". I'm not cool or aloof; I'm usually passionate and determinedly optimistic - "hey, how about this. It would turn the problem on its head and make it a neat opportunity."

That's helpful behavior except when it becomes more about me and less about the Other I'm supposedly helping, when it becomes a way to shift the issue away from what the other person needs to what I'm good at doing: problem-solving, idea generation, and talking. I'm using the Context as a way of making my Self comfortable. The solution (there I go again) is to make sure to let the Other guide the conversation.

I bet Dawn (who's witnessed more of this from me than anyone else has) would describe it as stereotypically male behavior. It probably is statistically more common among males. But I'd be willing to bet it's an occupational hazard for consultants.

So, by Box's criterion that all models are wrong, but some are useful, Satir's model is useful. I don't use it much, though.

## Posted at 18:31 in category /misc [permalink] [top]

About Brian Marick
I consult mainly on Agile software development, with a special focus on how testing fits in.

Contact me here: marick@exampler.com.

 

Syndication

 

Agile Testing Directions
Introduction
Tests and examples
Technology-facing programmer support
Business-facing team support
Business-facing product critiques
Technology-facing product critiques
Testers on agile projects
Postscript

Permalink to this list

 

Working your way out of the automated GUI testing tarpit
  1. Three ways of writing the same test
  2. A test should deduce its setup path
  3. Convert the suite one failure at a time
  4. You should be able to get to any page in one step
  5. Extract fast tests about single pages
  6. Link checking without clicking on links
  7. Workflow tests remain GUI tests
Permalink to this list

 

Design-Driven Test-Driven Design
Creating a test
Making it (barely) run
Views and presenters appear
Hooking up the real GUI

 

Popular Articles
A roadmap for testing on an agile project: When consulting on testing in Agile projects, I like to call this plan "what I'm biased toward."

Tacit knowledge: Experts often have no theory of their work. They simply perform skillfully.

Process and personality: Every article on methodology implicitly begins "Let's talk about me."

 

Related Weblogs

Wayne Allen
James Bach
Laurent Bossavit
William Caputo
Mike Clark
Rachel Davies
Esther Derby
Michael Feathers
Developer Testing
Chad Fowler
Martin Fowler
Alan Francis
Elisabeth Hendrickson
Grig Gheorghiu
Andy Hunt
Ben Hyde
Ron Jeffries
Jonathan Kohl
Dave Liebreich
Jeff Patton
Bret Pettichord
Hiring Johanna Rothman
Managing Johanna Rothman
Kevin Rutherford
Christian Sepulveda
James Shore
Jeff Sutherland
Pragmatic Dave Thomas
Glenn Vanderburg
Greg Vaughn
Eugene Wallingford
Jim Weirich

 

Where to Find Me


Software Practice Advancement

 

Archives
All of 2006
All of 2005
All of 2004
All of 2003

 

Join!

Agile Alliance Logo